Cursor gets lost if you click inside a custom element inside a <div contenteditable> |
||
Issue descriptionChrome Version: 64.0.3282.186 (Official Build) (64-bit) OS: Mac What steps will reproduce the problem? (1) Go to http://output.jsbin.com/xopinor (full code here: http://jsbin.com/xopinor/edit?html,output) (2) Click on the yellow box. (3) Press any of the arrows. Left Arrow. Right Arrow. Your cursor is lost. What is the expected result? The cursor should not get lost inside of custom element, and should be able to get out after some left/right arrows. If you have text on the page, up and down actually starts scrolling, so I'm not sure where the activeElement is. What happens instead? The cursor is lost forever. This also happens on Safari, so I'm suspicious it might be a contenteditable bug (from webkit), and not shadow DOM related, but I'm just making things up at this point. Related: https://bugs.chromium.org/p/chromium/issues/detail?id=821578
,
Mar 15 2018
Mark WontFix since "contenteditble" doesn't propagate crossing shadow boundary. In this example, if you want to edit "SKIP ME" which is in shadow root, you could write: <span contenteditable>SKIP ME</span>. Note: <span contenteditable>SKIP ME</span> establishes new editing host, typing Ctrl+A inside "SKIP ME", select whole "SKIP ME", but whole document.
,
Mar 15 2018
So in other words, it sounds like the OP example is the same as this example: http://jsbin.com/dohuleyulu/edit?html,output
,
Mar 15 2018
Domenic, in your example, is that intended behaviour? I guess I don't really know what i'd expect (other than the not-contenteditable span to not be clickable, i guess)
,
Mar 15 2018
Hmm, good question. Per http://jsbin.com/yuxojefohu/2/edit?html,output it looks like clicking on the non-contenteditable span focuses the closest focusable thing, which is the contenteditable div. But I guess resets the cursor? That is a bit surprising, but cursors and focusability are pretty complex. At this point yosin@, the editing expert, would be the best person to answer. Probably the editing folks have more background on our choices for non-editable regions inside of editable regions.
,
Mar 15 2018
I don't think it's a reasonable user experience to have clicking on *anything* in a contentEditable region mean that you lose the selection inside the contentEditable. It should either put the cursor before or after the element. The point is not that the content of the shadow DOM should be editable, I think we all agree it shouldn't be. But the cursor should go somewhere reasonable. I should be able to click and then use arrow keys to move the cursor around or type and have the typing actually work.
,
Mar 15 2018
We never show the cursor or allow you to move it with the arrow keys when you're in a non-editable element. It's like how clicking in a non-editable paragraph doesn't show an insertion point and doesn't let you move the selection with the arrow keys. It does seem kind of curious that in the original JS Bin: http://output.jsbin.com/xopinor it's not possible to position the cursor in between "SKIP ME" and the following period. Is this a bug?
,
Mar 15 2018
(never mind, that's already linked in the original report: https://bugs.chromium.org/p/chromium/issues/detail?id=821578) |
||
►
Sign in to add a comment |
||
Comment 1 by kochi@chromium.org
, Mar 14 2018Status: Assigned (was: Untriaged)