Title: [134536] trunk/Source/WebCore
- Revision
- 134536
- Author
- commit-qu...@webkit.org
- Date
- 2012-11-13 21:19:15 -0800 (Tue, 13 Nov 2012)
Log Message
Don't mark scrolling contents as dirty if RenderLayerBacking is going away
https://bugs.webkit.org/show_bug.cgi?id=101947
Patch by Sami Kyostila <skyos...@chromium.org> on 2012-11-13
Reviewed by Simon Fraser.
When a scrolling contents graphics layer is created or destroyed, the
associated graphics layer is marked as needing display because some of
the painted content may have migrated between the primary graphics layer
and the scrolling layer.
This causes a problem when the RenderLayerBacking is being destroyed,
because setNeedsDisplay() needs to check from the compositor whether to
track repaints or not. If the RenderLayerBacking is being destroyed, the
value returned by compositor() is garbage and this causes a crash.
This patch fixes the problem by making RenderLayer::compositor() return a null
pointer when the renderer no longer has a view.
Covered by existing layout tests in compositing/overflow/.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::compositor):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (134535 => 134536)
--- trunk/Source/WebCore/ChangeLog 2012-11-14 05:12:22 UTC (rev 134535)
+++ trunk/Source/WebCore/ChangeLog 2012-11-14 05:19:15 UTC (rev 134536)
@@ -1,3 +1,28 @@
+2012-11-13 Sami Kyostila <skyos...@chromium.org>
+
+ Don't mark scrolling contents as dirty if RenderLayerBacking is going away
+ https://bugs.webkit.org/show_bug.cgi?id=101947
+
+ Reviewed by Simon Fraser.
+
+ When a scrolling contents graphics layer is created or destroyed, the
+ associated graphics layer is marked as needing display because some of
+ the painted content may have migrated between the primary graphics layer
+ and the scrolling layer.
+
+ This causes a problem when the RenderLayerBacking is being destroyed,
+ because setNeedsDisplay() needs to check from the compositor whether to
+ track repaints or not. If the RenderLayerBacking is being destroyed, the
+ value returned by compositor() is garbage and this causes a crash.
+
+ This patch fixes the problem by making RenderLayer::compositor() return a null
+ pointer when the renderer no longer has a view.
+
+ Covered by existing layout tests in compositing/overflow/.
+
+ * rendering/RenderLayer.cpp:
+ (WebCore::RenderLayer::compositor):
+
2012-11-13 Erik Arvidsson <a...@chromium.org>
Update DOMException name: InvalidCharacterError
Modified: trunk/Source/WebCore/rendering/RenderLayer.cpp (134535 => 134536)
--- trunk/Source/WebCore/rendering/RenderLayer.cpp 2012-11-14 05:12:22 UTC (rev 134535)
+++ trunk/Source/WebCore/rendering/RenderLayer.cpp 2012-11-14 05:19:15 UTC (rev 134536)
@@ -262,7 +262,8 @@
#if USE(ACCELERATED_COMPOSITING)
RenderLayerCompositor* RenderLayer::compositor() const
{
- ASSERT(renderer()->view());
+ if (!renderer()->view())
+ return 0;
return renderer()->view()->compositor();
}
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-changes
