656626 - innerHTML reports a superfluous HTMLBRElement after editing a heading with contenteditable set to true

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Klaus Förster]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When you edit a heading that has its contenteditable attribute set to true and add spaces at its end, an extra HTMLBRElement is reported by innerHTML after the last space. Once it is added, there is no way to get rid of it anymore. When you add characters instead of spaces, no HTMLBRElement is added.

Reproducible: Always

Steps to Reproduce:
follow instructions at URL that demonstrates the problem

Actual Results:  
one HTMLBRElement is reported at the end of the string

Expected Results:  
no HTMLBRElement should be reported at all

Comment 1

[Thomas Ahlblom]

Reproduced.
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1
Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows NT 6.0; rv:6.0a1) Gecko/20110514 Firefox/6.0a1

Comment 2

[Thomas Ahlblom]

Attachment: Testcase from http://svg.cc/posts/contenteditable_br_bug_ff4.html

I attached the testcase in case it gets deleted from the web server.

Comment 3

[(no longer active)]

Boris, do you think that the HTML encoder should treat the bogus BR node especially (by excluding it from the output)?

Comment 4

[Boris Zbarsky [:bzbarsky]]

That would be pretty odd... and also the bogus BR node is in the DOM anyway, no?  So you can detect its presence in other ways.

Can we somehow avoid putting it there to start with?

Comment 5

[(no longer active)]

(In reply to comment #4)
> Can we somehow avoid putting it there to start with?

I will hopefully remove it some day, but that's a rather large project...

Comment 6

[Boris Zbarsky [:bzbarsky]]

In that case, I wouldn't worry too much about this bug for now....

Comment 7

[Alexander Ebert]

… and 8 years later, this bug is still around. This also applies to block elements like <p>, resulting in quite some messed up HTML markup.

<div contenteditable="true"><p>Test</p></div>

Adding a space after "Test" yields a <br> too, regardless of any content before or after that <p>.

Comment 8

[Mike Taylor [:miketaylr]]

Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=503838?