[webkit-reviews] review requested: [Bug 20909] REGRESSION (r35318): A press release at pfizer.com does not display correctly : [Attachment 28764] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 19 14:48:29 PDT 2009


Beth Dakin <bdakin at apple.com> has asked  for review:
Bug 20909: REGRESSION (r35318): A press release at pfizer.com does not display
correctly
https://bugs.webkit.org/show_bug.cgi?id=20909

Attachment 28764: Patch
https://bugs.webkit.org/attachment.cgi?id=28764&action=review

------- Additional Comments from Beth Dakin <bdakin at apple.com>
Okay, here is a new patch that works for the reduction AND the original Pfizer
page. I am not sure it is the best way to fix the problem. Here is a summary of
the problem:

When we add the generated content to the owner, the owner itself is not yet
attached to the document…the call to
RenderObjectChildList::updateBeforeAfterContent() is propagated through
Node::createRendererIfNeeded(), and it is called before the new renderer (for
the "owner") is actually added to the document. So when we add the generated
content and the generated content container as children of the owner, we call
setNeedsLayoutAndPrefWidthsRecalc(). This call propagates up the container
hierarchy. However, since the owner has not been added to the document just
yet, the hierarchy is not very long. 

So then, after all of that is done, the owner is added to the document back in
Node::createRendererIfNeeded(). So again, setNeedsLayoutAndPrefWidthsRecalc()
is called from within  the addChild() call. However, it doesn't end up
propagating up the hierarchy this time either because of this optimization in
RenderObject::setPrefWidthsDirty():

if (b && !alreadyDirty && markParents && (isText() || (style()->position() !=
FixedPosition && style()->position() != AbsolutePosition)))
	invalidateContainerPrefWidths();

alreadyDirty is true because this function was already called for the owner of
the generated content back when the generated content was added.

What I don't understand is why this bug only gets exposed in this weird timing
situation. In other words, I don't know how we ever get it right!

All of that being said, I could imagine this bug being fixed in a number of
other places, and I would love some feedback on moving or optimizing this fix.


More information about the webkit-reviews mailing list