1449936 - Unexpected behavior for input in contenteditable="false" nested in a contenteditable

Status: RESOLVED DUPLICATE of bug 1506547

(Core :: DOM: Editor, defect, P3)

Description

[hello]

Attachment: test.html

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

Comment 1

[soreine.plume]

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

[Ryan Lee Sipes]

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

[Makoto Kato [:m_kato]]

(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?

Comment 4

[hello]

Thanks for the update! I confirm that the bug is fixed, we are updating the article 👌