1639587 - Forward-deleting empty paragraph keeps a linebreak in designMode=true

Status: NEW

(Core :: DOM: Editor, defect)

Description

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

Attachment: paragraph-deletion2.html

1. Open the attachment
2. Put the caret at the end of the first paragraph
3. Press Delete button to delete in forward direction

Expected: The last paragraph should disappear
Actual: It keeps a linebreak that never disappears by forward deletion

Comment 1

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

Attachment: paragraph-deletion2.html

Comment 2

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

This somehow does not repro with contenteditable but only with designMode. Contenteditable shows another bug that undoing introduces duplicated paragraphs, though.

Comment 3

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

Modifying HTMLEditor::IsVisibleBRElement to consider a lonely <br> inside a block as visible fixes this.

But the function looks like a duplicate of nsLayoutUtils::IsInvisibleBreak, do we have a reason not to call it instead?

Comment 4

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

Probably, it's duplicated for that editor won't be broken by layout team's changes. As you know, editor module does not have enough automated tests even though its functions are really complicated (especially before WPT comes into the tree). So, the isolation must have been important for this reason.

And also, nsLayoutUtils::IsInvisibleBreak() refers layout information. It returns correct and actual state, but it may require latest layout information. For example, immediately after inserting a <br> element, it returns different result unless you flush pending notifications. If we did it, perhaps, execCommand speed would become slower and some benchmark score might become worse. So, I think that we should keep current style unless the difference of them causes actual problem.

Comment 5

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

Haven't been working on it, unassigning myself...