1513303 - contenteditable element breaks :empty selector in presence of pseudo elements

Status: NEW

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

Description

[Steven Luscher]

Attachment: empty_does_not_match_after_deleting_text.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

1. Prepare a contenteditable element that renders a placeholder using the ::before technique (https://codepen.io/anon/pen/dwoNwp); Observe placeholder.
2. Type into element.
3. Delete all content from element.


Actual results:

Observe that the :empty selector no longer matches, despite the element having arguably been emptied out.


Expected results:

Since the user deleted all of the contents, the :empty selector should have matched again, restoring the placeholder pseudo element.

Comment 1

[Edgar Chen [:edgar]]

I could reproduce this with latest Nightly on Mac and Window 10.

Comment 2

[Edgar Chen [:edgar]]

It looks like we leave a <br> element under contenteditable element, so it doesn't match the :empty selector. And it could be recovered by pressing enter and then deleting all content again.

Comment 3

[jscher2000]

(In reply to Edgar Chen [:edgar] from comment #2)

It looks like we leave a <br> element under contenteditable element, so it
doesn't match the :empty selector. And it could be recovered by pressing
enter and then deleting all content again.

The same behavior in the editor creates problems for users of Google Sheets: opening the editor on a cell and clearing an existing value before typing a new one injects <br> between those steps, which is invisible during editing and seemingly impossible to remove afterwards.

• https://support.mozilla.org/questions/1272896
• https://bugzilla.mozilla.org/show_bug.cgi?id=1192656 (closed after evangelism, but unsolved)

Tester page: https://www.jeffersonscher.com/res/editor-newline.html

Comment 4

[sergeykish]

Caused by extra <br> https://bugzilla.mozilla.org/show_bug.cgi?id=744408