Bug 122027

Summary: ASSERTION FAILED: foundContainer in RenderGeometryMap::mapToContainer(WebCore::TransformState &, const WebCore::RenderLayerModelObject *) const
Product: WebKit Reporter: zalan <zalan>
Component: Layout and RenderingAssignee: zalan <zalan>
Status: ASSIGNED    
Severity: Normal CC: cadubentzen, jeffrey+webkit, rhodovan.u-szeged, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
test reduction none

zalan
Reported 2013-09-27 12:05:31 PDT
SSIA
Attachments
test reduction (159 bytes, text/html)
2013-09-27 12:06 PDT, zalan 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
zalan
Comment 1 2013-09-27 12:06:29 PDT
Created attachment 212830 [details] test reduction
zalan
Comment 2 2013-09-27 12:07:04 PDT
<rdar://problem/15082483>
zalan
Comment 3 2013-09-27 12:31:32 PDT
This happens when the layout container tree != painting container tree. With CSS filters (blur in this case), when a child element is (absolute)positioned, its parent in layout terms might differ from its parent in painting terms. The geometry map is initiated with layout containers, but in RenderLayer::updateLayerPositionsAfterScroll(), we pass the repaint container to the mapping function, which in turn fails to transform the coordinates as repaint container != layout container ->assert. -see computeRepaintRects(renderer().containerForRepaint(), geometryMap);
Vicki Pfau
Comment 4 2013-10-08 13:20:58 PDT
This is likely the same bug as https://bugs.webkit.org/show_bug.cgi?id=117981
zalan
Comment 5 2013-11-13 14:56:01 PST
*** Bug 117981 has been marked as a duplicate of this bug. ***
zalan
Comment 6 2013-11-13 20:40:08 PST
(In reply to comment #3) > This happens when the layout container tree != painting container tree. > With CSS filters (blur in this case), when a child element is (absolute)positioned, its parent in layout terms might differ from its parent in painting terms. The geometry map is initiated with layout containers, but in RenderLayer::updateLayerPositionsAfterScroll(), we pass the repaint container to the mapping function, which in turn fails to transform the coordinates as repaint container != layout container ->assert. -see computeRepaintRects(renderer().containerForRepaint(), geometryMap); Let me rephrase it. The container tree for the absolute positioned object is not the same as the painting tree unless the parent has transform or it is positioned too. In this case, the parent has CSS filter only and while it requires a dedicated render layer, when it comes to figuring out the containing block, it is skipped.
Carlos Bentzen
Comment 7 2018-12-03 14:36:12 PST
I just hit this assertion in WPE running Youtube TV.
Note You need to log in before you can comment on or make changes to this bug.