1664664 - Odd div element contenteditable line-break behavior

Status: NEW

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

Description

[skisby2]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Odd behavior #1

If, in a contenteditable div container, we render:
innerText: "That was not a coherent comment.\nThis may be.Can we still modify?"
innerHTML: "<div>That was not a coherent comment.<div></div>This may be.Can we still modify?</div>"

Then GUI insert a line-break before "Can", oddly we wind up with:
innerText: "That was not a coherent comment.This may be.\nCan we still modify?"
innerHTML: "<div>That was not a coherent comment.This may be.</div><div>Can we still modify?</div>"

If you GUI insert a line-break before the rendered line break, it works correctly. That is, the originally rendered line-brake is not removed.

Odd behavior #2

If, in a contenteditable div container, we render:
innerText: "That was not a coherent comment.\nThis may be.Can we still modify?"
innerHTML: "<div>That was not a coherent comment.<div></div>This may be.Can we still modify?</div>"

Then GUI insert the cursor just before "This" and press the Back-Space (Rubout) key, that should remove the line-break but nothing happens. If the cursor is then GUI inserted immediately after the period in "comment." and the Del key is pressed, the line-break is correctly removed.

Odd behavior #3

Rather than rendering line-breaks with <div></div> I tried rendering line-breaks with <br>. That resolved in no odd behaviour #2 but a variation of odd behaviour #1 as follows.

If, in a contenteditable div container, we render:
innerText: "That was not a coherent comment.\nThis may be.Can we still modify?"
innerHTML: "That was not a coherent comment.<br>This may be.Can we still modify?"

Then GUI insert a line-break before "Can", oddly we wind up with:
innerText: "That was not a coherent comment.\n\nThis may be.\nCan we still modify?"
innerHTML: "That was not a coherent comment.<br><div>This may be.</div><div>Can we still modify?</div>"

That is, the erroneous extra line-break inserted before "This" is not immediately displayed, but gets written out into a database. When the text of that contenteditable div container is re-rendered from that database, the extra line-break is then displayed.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't understand "GUI" in this context. The reported innerHTML cases are in WPT, therefore, it should work with raw DOM. Do you use framework or something editor library to write a rich teext editor?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:edgar, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Edgar Chen [:edgar]]

(In reply to skisby2 from comment #0)

Odd behavior #1

If, in a contenteditable div container, we render:
innerText: "That was not a coherent comment.\nThis may be.Can we still modify?"
innerHTML: "<div>That was not a coherent comment.<div></div>This may be.Can we still modify?</div>"

Then GUI insert a line-break before "Can", oddly we wind up with:
innerText: "That was not a coherent comment.This may be.\nCan we still modify?"
innerHTML: "<div>That was not a coherent comment.This may be.</div><div>Can we still modify?</div>"

If you GUI insert a line-break before the rendered line break, it works correctly. That is, the originally rendered line-brake is not removed.

I guess the reporter means pressing enter key to insert a line-break before "Can".
I could reproduce #1 behavior on https://codepen.io/edgarchen-the-decoder/full/vYzBMVB.

The original DOM tree,

<div contenteditable id="target"><div>That was not a coherent comment.<div></div>This may be.Can we still modify?</div></div>

In Gecko, after pressing enter key before "Can", DOM tree becomes to

<div id='target' contenteditable=''><div>That was not a coherent comment.This may be.</div><div>Can we still modify?</div></div>

But in Chrome, after pressing enter key before "Can", DOM tree becomes to

<div id='target' contenteditable=''><div>That was not a coherent comment.<div></div>This may be.</div><div>Can we still modify?</div></div>

I didn't test other case though.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you! That's caused by a known issue that how to handle contents not in default paragraph under editing host.