New issue
Advanced search Search tips

Issue 605433 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 463348



Sign in to add a comment

Incorrect cursor display after passing a contenteditable=false island at the end of a paragraph

Reported by dive...@gmail.com, Apr 21 2016

Issue description

UserAgent: 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.
 

Comment 1 by yosin@chromium.org, Apr 21 2016

Components: -Blink Blink>TextSelection
Labels: -OS-Linux OS-All
Status: Available (was: Unconfirmed)

Comment 2 Deleted

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.
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.

Comment 5 by tkent@chromium.org, Oct 12 2016

Components: -Blink>TextSelection Blink>Editing>Selection

Comment 6 by tkent@chromium.org, Jan 19 2017

Blocking: 463348

Comment 7 by yosin@chromium.org, Oct 4 2017

Labels: Pri-3
Project Member

Comment 8 by sheriffbot@chromium.org, Oct 4

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Status: Available (was: Untriaged)
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