Hi, when a accelerated composition is turned off on a page (for example, because no element require compositing anymore), WebKitGTK often crashes in #0 0xb68f063f in WebKit::AcceleratedCompositingContext::flushPendingLayerChanges() () from /home/arno/webkit/WebKit.upstream/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0 #1 0xb68f06f5 in WebKit::AcceleratedCompositingContext::flushAndRenderLayers() () from /home/arno/webkit/WebKit.upstream/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0 #2 0xb68f07e0 in WebKit::AcceleratedCompositingContext::layerFlushTimerFired() () from /home/arno/webkit/WebKit.upstream/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0 #3 0xb68f0801 in WebKit::AcceleratedCompositingContext::layerFlushTimerFiredCallback(WebKit::AcceleratedCompositingContext*) () flushPendingLayerChanges is reached while m_rootLayer has been cleared, and this results in a crash. This happens because frame->view()->updateLayoutAndStyleIfNeededRecursive() is called in flushAndRenderLayers, and this may result in root compositing layer being set to null.
Created attachment 166579 [details] Patch patch proposal: check if compositing is enabled after call to updateLayoutAndStyleIfNeededRecursive
Comment on attachment 166579 [details] Patch Nice fix. It probably makes sense to keep the check in both places, no?
Created attachment 166581 [details] Patch updated patch
Comment on attachment 166581 [details] Patch Thanks!
Comment on attachment 166581 [details] Patch Clearing flags on attachment: 166581 Committed r130108: <http://trac.webkit.org/changeset/130108>
All reviewed patches have been landed. Closing bug.