Unexpected behavior for input in contenteditable="false" nested in a contenteditable
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
People
(Reporter: hello, Unassigned)
Details
Attachments
(1 file)
776 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce: 1. Create a div with "contenteditable" 2. Create a div inside the previous one, this time with "contenteditable=false" 3. Create an input inside the non-editable div The input's behavior is unexpected: left/right arrow keys no more moves the caret to the left/right. Also, window.getSelection() returns "Restricted" anchorNode and focusNode (accessing any of their properties will throw an error). I attached the test case, it's also available here: https://jsfiddle.net/hsqebsk2/ This bug might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1381620 (not so sure as it seems specific to the <input type="range" /> or videos). Actual results: * Left/right arrow keys don't move the caret * window.getSelection() returns a Selection with "Restricted" anchorNode and focusNode Expected results: * Left/right arrow keys should move the caret * window.getSelection() should return non-restricted DOM nodes for anchorNode and focusNode
Updated•7 years ago
|
Comment 1•6 years ago
|
||
This is critical for any website that uses content editable seriously. It makes it impossible to use inputs when implementing, for example, a WYSIWYG editor. Is this considered a security issue to have `window.getSelection()` return a non-restricted DOM node there ? Is there any way we can help aligning Firefox with other browsers on that matter ?
Comment 2•6 years ago
|
||
Hey Makoto, could we get an update on this. Gitbook appears to have raised this as an issue with their users, and it's not a good look: https://medium.com/gitbook/about-editing-issues-on-firefox-1aa63c9c80d
Looks like they'd like to help get to a solution.
Comment 3•6 years ago
|
||
(In reply to Ryan Sipes from comment #2)
Hey Makoto, could we get an update on this. Gitbook appears to have raised this as an issue with their users, and it's not a good look: https://medium.com/gitbook/about-editing-issues-on-firefox-1aa63c9c80d
Looks like they'd like to help get to a solution.
Original issue that is reported by reporter are already fixed by bug 1506547. If your issue occurs on Firefox Nightly 67, could you file a new bug for it?
Thanks for the update! I confirm that the bug is fixed, we are updating the article 👌
Description
•