Summary: | Impossible to place caret at the start of a text node | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Tim Down <timdown> | ||||
Component: | HTML Editing | Assignee: | 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
Tim Down
2009-01-08 10:17:23 PST
Created attachment 26527 [details]
Test case
Any chance of progress with this and related selection bugs? 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. (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. (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!!! |