1723480 - Contenteditable with a table inside - FF adds a BR tag in empty TD cells

Status: RESOLVED WORKSFORME

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

Description

[Christina]

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

Steps to reproduce:

Background: I have contenteditable DIV, and, inside it, a table. Table cells have paragraphs of text in them. Some of the cells have empty P tags initially. Later, text is loaded into those cells using Javascript.
Platform: FF 90.0.2 (64-bit) on a MacOS Big Sur 11.4
Repro notes: the outside DIV must be contenteditable, or else the issue doesn't occur. It also has to be cells in a table - nothing of the sort happens in my non-table DIVs.

HTML to reproduce the problem:
<div contenteditable="true">
<table>
<tbody>
<tr>
<td><p id="myParagraph1"></p></td>
</tr>
</tbody>
</table>
</div>

<script>
document.getElementById("myParagraph1").textContent = "My cool text 1";
</script>

Actual results:

1. The TD element starts out with an empty P tag in it. Inspecting it reveals that the TD contains the P and also a rogue BR tag. Other browsers do not add the BR tag in this way.
2. Once I add text using Javascript, the P tag is no longer empty. However, the BR remains there.

Expected results:

The BR tag should not be added. It's surprising to find a difference between the HTML I load up, and what it looks like in the browser.
The fact that the BR stays even after the text has been loaded is even stranger.

Known workaround: handle the empty text differently. If the text is empty, place a single BR inside the TD. If the text is not empty, place a P. This also works when using JS-based frameworks with virtualdom; and it functions normally in other browsers also.

Comment 1

[Christina]

https://jsbin.com/xiducanuxe/1/edit?html,output
P.S.: it was repro'ed using a clean FF profile without extensions.

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

I guess this is the HTMLEditor behavior that adds <br>.

Comment 4

[Kagami Rosylight [:saschanaz] (they/them)]

... or not, since a table cell is not an "empty editor"? What do you think, Masayuki?

Comment 5

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

I'm not sure whether it's a padding <br> element for empty editor or empty last line. Anyway, we need a long journey for fixing this.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Thanks for setting the correct issue dependency!

Comment 7

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

The patches for bug 1923251 makes it clean up unnecessary <br> elements immediately before a block boundary.

Currently, we still need a <br> in each table cell because of a placeholder of caret to make users possible to modify empty cell (users cannot move caret into the cell, but Selection API can do it). Chrome allows to move caret into truly empty cells.
testcase: https://d-toybox.com/studio/lib/input_event_viewer.html?editor=contenteditable&innerHTML=before%3Ctable+border%3E%3Ctd%3E%7B%7D%3C%2Ftd%3E%3Ctd%3E%3C%2Ftd%3E%3C%2Ftable%3Eafter&whiteSpace=normal

So, for stop inserting <br> elements into empty cells, we need to fix the bug of our caret navigation.

On the other hand, I'm not sure whether the expected behavior of this bug is better than current behavior. When I delete the last character in a cell on Chrome, they insert a <br> like Gecko. So, from the web-compat point of view, we should not change current behavior after edit.

Anyway, I don't see any bogus <br>s within the testcase in comment 1.