[Webkit-unassigned] [Bug 20909] REGRESSION (r35318): A press release at pfizer.com does not display correctly

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20909


bdakin at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-                     |bdakin at apple.com
                   |unassigned at lists.webkit.org |
  Attachment #28764|                            |review?
               Flag|                            |




------- Comment #23 from bdakin at apple.com  2009-03-19 14:48 PDT -------
Created an attachment (id=28764)
 --> (https://bugs.webkit.org/attachment.cgi?id=28764&action=view)
Patch

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. 


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.