Bug 6608 – REGRESSION: Line disappears when deleting

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Duncan Wilcox]

When running Mail.app on TOT, do the following:

- reply to any message
- type "asdfghj" + enter
- notice two new lines appear instead of one
- arrow right, arrow right
- now the cursor is before "On <date>, <name> wrote:"
- backspace, backspace
- the whole line disappears

These might be two separate bugs, but I think the appearance of an extra line and disappearing of 
another might be related.

[Joost de Valk (AlthA)]

Adding Regression keyword.

[Joost de Valk (AlthA)]

Upping to P1 because this is a regression.

[Alice Liu]

<rdar://problem/4424044>

[Justin Garcia]

Spun the extra line appearing problem into a separate bug (8075).

[Justin Garcia]

Created attachment 7391 [details]
patch

Rewrote moveNodesAfterNode to address several problems:
It moves nodes w/o worrying about how their style might change during the move.
It traverses _siblings_ looking for a br to know that it's at the end of the paragraph to merge.  If the br is burried inside a span, it won't find it.  If the text is whitespace:pre, it won't find stop at the end of the paragraph.
It reinserts the nodes at strange places, which was causing the bug.

This patch passes all pixel tests.  Render tree diffs are 1) fixes 2) placeholder brs were there were none.  This patch inserts them more aggressively to make sure that inline content after the merged paragraph doesn't collapse onto the line where the paragraph was moved to.  I'm writing lots of layout tests to illustrate problems with the old function and thinking hard about how to break the new code.

[Darin Adler]

Comment on attachment 7391 [details]
patch

Are you guaranteed that removing a node won't cause it's parent to be deref'd? If not, the Node* might need to be RefPtr<Node>.

+    void removeNodeAndPruneAncestors(WebCore::Node* node);
+    void prune(WebCore::Node* node);

No need for WebCore:: prefixes here.

r=me

[Justin Garcia]

(In reply to comment #6)
> (From update of attachment 7391 [details] [edit])
> Are you guaranteed that removing a node won't cause it's parent to be deref'd?
> If not, the Node* might need to be RefPtr<Node>.

I guess a removal listener on the node to remove could remove/deref the parent.  There are lots of places in the editing code where the possibility is ignored, of course.