Bug 23189 – Impossible to place caret at the start of a text node

• Component: HTML Editing
• Status: NEW

[Tim Down]

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.

[Tim Down]

Created attachment 26527 [details]
Test case

[Tim Down]

Any chance of progress with this and related selection bugs?

[Ted Rust]

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]

(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]

(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]

<rdar://problem/97590553>

[Radar WebKit Bug Importer]

<rdar://problem/97590632>

[Ryosuke Niwa]

This and the bug 15256 are basically identical problem.