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

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


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)

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

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

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.

More information about the webkit-unassigned mailing list