[Webkit-unassigned] [Bug 57052] Infinite Re-layout Loop

Wed Mar 30 13:54:28 PDT 2011

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

Fady Samuel <fsamuel at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|WebCore Misc.               |SVG
                 CC|                            |zimmermann at kde.org

--- Comment #4 from Fady Samuel <fsamuel at chromium.org>  2011-03-30 13:54:28 PST ---
(In reply to comment #3)
> Created an attachment (id=87605)
 --> (https://bugs.webkit.org/attachment.cgi?id=87605&action=review) [details]
> Infinite Relayout Loop reduction
> 
> Sorry for the delay. I had a hard time deciding whether this was a platform-specific bug or a general bug, and what exactly was causing it. It seems to be an SVG bug. I will describe the issue in detail in comments.

So here's what's going on:

>From a high level here, we have two divs (two RenderBoxes) that have the same SVG as a background image. The background layer for each box has a StyleCachedImage proxy object, to a single *SHARED* CachedImage object. This, in turn, has access to an SVGImage object which creates a *fake* page containing an SVGDocument, and SVGSVGElement root element. 

When a RenderBox is in the process of laying out, at some point RenderBoxModelObject::calculateFillTileSize (called from RenderBox::calculateBackgroundImageGeometry) is called. Inside that method, image->setImageContainerSize(..) is called. This ultimately updates m_containerSize in SVGSVGElement (which is shared by the two boxes in this example) to the size of one of the containers. 

When SVGImage::draw is called to paint the background, it resizes the FrameView of the fake page to fit the SVGSVGElement (which is sized according to the other container). This triggers a FrameView::layout(). Ultimately, through FrameView::layout(), we reach ScrollView::repaintContentRectangle(..)which calls it's hostWindow's ChromeClient (which is an SVGImageChromeClient) to "invalidateContentsAndWindow", which then calls CachedImage::changedInRect(..). 

This causes the CachedImage to inform its observers (the two RenderBoxes in this case), that the imageChanged (RenderBox::imageChanged)which eventually calls RenderBox::calculateBackgroundImageGeometry through  RenderBox::repaintLayerRectsForImage. 

...and so we have a huge, super-nasty infinite loop. Please message me if you'd like more information or discuss solutions. I'm eager to think further about this.

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