Missing bidi visual cursor position in contenteditable at directionality boundary
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 style="padding:0.5em" dir=rtl contenteditable>ABC<span contenteditable=false>XYZ</span>אבג</h1> Steps to reproduce the problem: 1. Open the data URI above 2. Click at the left-most position and try to cursor visually rightwards with the right arrow key 3. Observe that the cursor gets stuck before 'XYZ' What is the expected behavior? The cursor should be able to cross 'XYZ' and land visually to the right of XYZ. What went wrong? Note that in the non-bidi case (e.g. data:text/html,<h1 contenteditable>XYZ<span contenteditable=false>xyz</span></h1> ), the cursor will successfully cross a contenteditable=false island at the end of the paragraph. (However there is a display glitch: see https://bugs.chromium.org/p/chromium/issues/detail?id=605433 ) Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 48.0.2564.82 Channel: n/a OS Version: Flash Version:
,
Apr 21 2016
,
Apr 22 2016
,
Apr 26 2016
,
May 23 2016
Removing Blink>RTL.
,
Oct 12 2016
,
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
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dive...@gmail.com
, Apr 21 2016A cursor visually at the end of the above example could represent the editable logical position { node: h1, offset: 2 } , or { node: h1, offset: 0 }. I suspect part of the issue is that neither of these look like canonical positions from the point of view of Chromium's position normalization.