[webkit-reviews] review requested: [Bug 7955] REGRESSION: Content with an interchange newline lost when pasted at the end of the document : [Attachment 7276] patch

bugzilla-request-daemon at opendarwin.org bugzilla-request-daemon at opendarwin.org
Fri Mar 24 01:58:31 PST 2006


Justin Garcia <justin.garcia at apple.com> has asked  for review:
Bug 7955: REGRESSION: Content with an interchange newline lost when pasted at
the end of the document
http://bugzilla.opendarwin.org/show_bug.cgi?id=7955

Attachment 7276: patch
http://bugzilla.opendarwin.org/attachment.cgi?id=7276&action=edit

------- Additional Comments from Justin Garcia <justin.garcia at apple.com>
Instead of getting rid of isProbablyBlock by keeping the replacement fragment
in the document during the paste operation, I keep a map from nodes to
RenderingInfos - a class that contains the style that a node had during the
test insertion, and a bool for whether or not its renderer was blockFlow during
the test insertion.

When I restore styles, I must do so in depth first order, so that restoring the
style on a node doesn't negate restoration I've done on its children.  To do
this, I traverse the fragment in depth first order during the test insertion,
putting nodes into a Vector in addition to putting them into the map.  Then I
restore styles to nodes in the order that they occur in the Vector.  At first I
tried to avoid using the Vector by passing fixupNodeStyles a range to operate
over, and traversing that range in depth first order.  But since style
restoration does an ApplyStyleCommand, which moves nodes around, wraps them in
new blocks, and splits and merges nodes, I wasn't completely confident that my
code would visit all of the nodes that were pasted.

I could have also left the code as-is and just added a HashMap<Node*, bool> for
the isBlockFlow checks, but I thought that paste might eventually need to save
even more information about the test insertion, like isInline.

The attached diff is between my tree and a revision before my patch was
checked-in.



More information about the webkit-reviews mailing list