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

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Fady Samuel <fsamuel at chromium.org>  2011-03-30 14:03:01 PST ---
Forgot to add: one RenderBox will see that the SVG hasn't "changed" and so it doesn't do anything. The other will see that the SVG has changed its size to that of the other RenderBox, and so the cycle repeats to reset SVGSVGElement.

(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=87605)
 --> (https://bugs.webkit.org/attachment.cgi?id=87605&action=review) [details] [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.