Summary: | REGRESSION: Line disappears when deleting | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Duncan Wilcox <duncan> | ||||
Component: | HTML Editing | Assignee: | Justin Garcia <justin.garcia> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | alice.barraclough, ap, harrison | ||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Attachments: |
|
Description
Duncan Wilcox
2006-01-16 23:27:39 PST
Adding Regression keyword. Upping to P1 because this is a regression. Spun the extra line appearing problem into a separate bug (8075). 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.
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
(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. |