ASSERT loading Acid3 test in run-safari --debug (r135050) ASSERTION FAILED: willBeComposited == needsToBeComposited(layer) /Users/eseidel/Projects/WebKit/Source/WebCore/rendering/RenderLayerCompositor.cpp(894) : void WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer *, WebCore::RenderLayer *, WebCore::RenderLayerCompositor::OverlapMap *, WebCore::CompositingState &, bool &, bool &) 1 0x10e6db5e5 WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WebCore::RenderLayer*, WebCore::RenderLayerCompositor::OverlapMap*, WebCore::CompositingState&, bool&, bool&) 2 0x10e6db52d WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WebCore::RenderLayer*, WebCore::RenderLayerCompositor::OverlapMap*, WebCore::CompositingState&, bool&, bool&) 3 0x10e6db52d WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WebCore::RenderLayer*, WebCore::RenderLayerCompositor::OverlapMap*, WebCore::CompositingState&, bool&, bool&) 4 0x10e6daac3 WebCore::RenderLayerCompositor::updateCompositingLayers(WebCore::CompositingUpdateType, WebCore::RenderLayer*) 5 0x10da6d0cd WebCore::FrameView::updateCompositingLayersAfterLayout() 6 0x10da6ecb3 WebCore::FrameView::layout(bool) 7 0x10da6a830 WebCore::FrameView::layoutTimerFired(WebCore::Timer<WebCore::FrameView>*) 8 0x10da865d3 WebCore::Timer<WebCore::FrameView>::fired() 9 0x10ec46af6 WebCore::ThreadTimers::sharedTimerFiredInternal() 10 0x10ec46889 WebCore::ThreadTimers::sharedTimerFired() 11 0x10e96d933 WebCore::timerFired(__CFRunLoopTimer*, void*) 12 0x7fff91112da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
See also discussion in https://bugs.webkit.org/show_bug.cgi?id=101303
Caused by http://trac.webkit.org/changeset/133807
This is obviously contributing to the red WK2 bots.
I've been investigating this today, and I looked at it a bit with Simon. The problem is that there is a bit of a circular dependency here. We're trying to figure out if we need to composite something that is positioned. But in the case where that positioned thing is out of view or has a size of (0,0), we don't really know if it needs to be composited until we have determined what's happening with its children. In this case, it seems like we probably hit this bug because there was a position:absolute box inside a position:fixed box. At first we thought the the position:fixed thing would be composited for the sake of the position:absolute thing. But then if the course of all of these calculations, it was determined that actually the position:absolute thing needs its own layer, so the position:fixed thing no longer needs to be composited for the sake of the position:absolute thing. Then we assert. Anyway, I have a patch for this that I will post shortly.
Created attachment 179201 [details] Patch
Thanks Beth. :)
Attachment 179201 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1 Source/WebCore/rendering/RenderLayerCompositor.cpp:2000: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3] Total errors found: 1 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 179381 [details] Patch
Comment on attachment 179381 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=179381&action=review > Source/WebCore/rendering/RenderLayerCompositor.cpp:1999 > + LayoutRect layerBounds = canBeComposited(layer) ? layer->calculateLayerBounds(rootRenderLayer(), 0, RenderLayer::DefaultCalculateLayerBoundsFlags I don't think we need the canBeComposited() check, since needsToBeComposited() already bails on this. I don't really know why calculateCompositedBounds() had it.
Thanks, Simon! http://trac.webkit.org/changeset/137690