Bug 23189

Summary: Impossible to place caret at the start of a text node
Product: WebKit Reporter: Tim Down <timdown>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ap, ayg, enrica, jparent, karlcow, michael.vm, rniwa, ted, webkit-bug-importer, webkit
Priority: P2 Keywords: BrowserCompat, InRadar
Version: 525.x (Safari 3.2)   
Hardware: All   
OS: All   
URL: http://www.timdown.co.uk/testcases/range.html
See Also: https://bugs.webkit.org/show_bug.cgi?id=15256
Attachments:
Description Flags
Test case none

Tim Down
Reported 2009-01-08 10:17:23 PST
In design mode, it is impossible to place the caret at the start of a text node. It is possible to create a collapsed Range at the start of a text node programmatically using JavaScript but if you add that range to the selection, the caret goes to the end of the node immediately prior to the text node, contrary to the behaviour in Firefox and Opera. For example, for the HTML Some text <span>more text</span> you create a collapsed Range at the start of "more text" and add that to the selection, in Opera and Firefox you get Some text <span>|more text</span> as expected, but in WebKit you get Some text |<span>more text</span> The URL for this bug has a simple test case. Bug #15256 is a special case of this bug and mentions the general case in the comments.
Attachments
Test case (1.29 KB, text/html)
2009-01-08 10:18 PST, Tim Down 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Tim Down
Comment 1 2009-01-08 10:18:24 PST
Created attachment 26527 [details] Test case
Tim Down
Comment 2 2010-04-14 03:57:39 PDT
Any chance of progress with this and related selection bugs?
Ted Rust
Comment 3 2012-06-27 09:55:47 PDT
I would love a resolution to this bug as well. We are currently trying to improve the functionality of some non-editable content in a design mode area. The first problem is if the non-editable content is the first or last element in the design mode element, it's not technically possible to get the cursor outside of the non-editable node without some DOM Range wizardry. The second problem is that when you do have an element directly following the non-editable region, there is no way to put the cursor at the beginning of the following node -- it always falls back to the end of the non-editable node. Similar DOM Range wizardry can magically place the cursor in the right place EXCEPT when that node is a text node and you are in a WebKit browser. Someone please let me know a decent way to work around this and I will be much relieved.
Tim Down
Comment 4 2012-06-27 10:54:58 PDT
(In reply to comment #3) > I would love a resolution to this bug as well. We are currently trying to improve the functionality of some non-editable content in a design mode area. The first problem is if the non-editable content is the first or last element in the design mode element, it's not technically possible to get the cursor outside of the non-editable node without some DOM Range wizardry. > > The second problem is that when you do have an element directly following the non-editable region, there is no way to put the cursor at the beginning of the following node -- it always falls back to the end of the non-editable node. Similar DOM Range wizardry can magically place the cursor in the right place EXCEPT when that node is a text node and you are in a WebKit browser. > > Someone please let me know a decent way to work around this and I will be much relieved. It's far from decent, but you may be able to use the fact that WebKit has a special case for <a> elements and allows the caret to be placed at the start inside an <a> element. Otherwise, you could place a zero-width characters at the start of any text node in which you want to place the caret. This is also obviously deeply non-decent.
Ted Rust
Comment 5 2012-06-27 12:04:56 PDT
(In reply to comment #4) > It's far from decent, but you may be able to use the fact that WebKit has a special case for <a> elements and allows the caret to be placed at the start inside an <a> element. Otherwise, you could place a zero-width characters at the start of any text node in which you want to place the caret. This is also obviously deeply non-decent. Thank you much for the reply. I was thinking along the same lines as you -- that is, put a zero-width character in the text node first, then place the cursor and clean up the zero-width character at some indeterminate future point. I am trying to do this on keypress, so I need to place the cursor, let the default action happen and then find some way to remove the zero-width character reliably and consistently. Again, thanks for the speedy and helpful response. What a pain this is to work around!!!
Radar WebKit Bug Importer
Comment 6 2022-07-26 00:03:49 PDT
<rdar://problem/97590553>
Radar WebKit Bug Importer
Comment 7 2022-07-26 00:05:47 PDT
<rdar://problem/97590632>
Ryosuke Niwa
Comment 8 2022-07-27 11:31:05 PDT
This and the bug 15256 are basically identical problem.
Note You need to log in before you can comment on or make changes to this bug.