Incorrect cursor display after passing a contenteditable=false island at the end of a paragraph
Reported by
dive...@gmail.com,
Apr 21 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/48.0.2564.82 Chrome/48.0.2564.82 Safari/537.36 Example URL: data:text/html,<h1 contenteditable>XYZ<span contenteditable=false>xyz</span></h1> Steps to reproduce the problem: 1. Open the data URI above 2. Click at the start, then press the right arrow key four times. 3. Note that the cursor appears between 'Z' and 'x' (as if it has not passed the ce=false span). What is the expected behavior? The cursor should appear after the 'xyz'. What went wrong? This is a just display bug; typing will insert text after 'xyz', and s=window.getSelection();[s.focusNode,s.focusOffset] shows that the cursor is actually at the end of the block (after the ce=false span). It seems to relate to Chromium's left-normalization of cursor positions. There is no problem with the reflected case where the contenteditable=false island is at the paragraph start. (That is, if you open data:text/html,<h1 contenteditable><span contenteditable=false>abc</span>ABC</h1> , click at the end, then press the left arrow key four times, then the cursor is correctly rendered before the 'a'). Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 48.0.2564.82 Channel: n/a OS Version: Flash Version: See also https://bugs.chromium.org/p/chromium/issues/detail?id=605418 - the case when the contenteditable=false island is visually, but not logically, at the end of the paragraph.
,
Sep 1 2016
There is no real workaround for this and it is currently making it very difficult to provide a reliable inline-editing solution within Chromium while all other current browsers support the standard contenteditable=false out of the box with no issue. In chromium a developer must either accept this strange behaviour, or avoid using "contenteditable=false" entirely and instead block the click event and selected keyup events, which is quite unreliable.
,
Sep 1 2016
It is actually possible to force Chrome 52.0.2743.116 to behave as expected if you just change a parameter in the element's DOM using Dev Tools. This seems to trigger a redraw and the cursor will render where expected.
,
Oct 12 2016
,
Jan 19 2017
,
Oct 4 2017
,
Oct 4
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
,
Oct 10
The behaviour in Chromium 69 is different (but still wrong): the cursor does not cross the contenteditable=false span at all. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by yosin@chromium.org
, Apr 21 2016Labels: -OS-Linux OS-All
Status: Available (was: Unconfirmed)