Title: [118452] trunk/Source/WebCore
- Revision
- 118452
- Author
- [email protected]
- Date
- 2012-05-24 17:46:41 -0700 (Thu, 24 May 2012)
Log Message
Layout root not getting cleared for anonymous renderers geting destroyed
https://bugs.webkit.org/show_bug.cgi?id=84002
Reviewed by Abhishek Arya.
This is a follow-up to r109406, which added a check to clear layout
roots when they point to a renderer that is being destroyed. The
thinking was that layout roots would never be anonymous renderers,
but there are some cases where this is not true (in particular,
generated content containers with overflow clips can be layout roots).
As in r109406, this patch has no layout test. This is because any test
that exercises this behavior is caused by an existing layout bug where
a child is not properly getting layout (or a renderer is getting dirtied
out of order during layout) and will fail multiple ASSERTs:
in particular, ASSERT(!m_layoutRoot->container() || !m_layoutRoot->
container()->needsLayout()) in FrameView::scheduleRelayoutOfSubtree(),
and ASSERT_NOT_REACHED() in RenderObject::clearLayoutRootIfNeeded().
We are preventing those bugs from manifesting as security issues with
this patch.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::~RenderObject):
(WebCore::RenderObject::willBeDestroyed):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (118451 => 118452)
--- trunk/Source/WebCore/ChangeLog 2012-05-25 00:33:06 UTC (rev 118451)
+++ trunk/Source/WebCore/ChangeLog 2012-05-25 00:46:41 UTC (rev 118452)
@@ -1,3 +1,30 @@
+2012-05-24 Ken Buchanan <[email protected]>
+
+ Layout root not getting cleared for anonymous renderers geting destroyed
+ https://bugs.webkit.org/show_bug.cgi?id=84002
+
+ Reviewed by Abhishek Arya.
+
+ This is a follow-up to r109406, which added a check to clear layout
+ roots when they point to a renderer that is being destroyed. The
+ thinking was that layout roots would never be anonymous renderers,
+ but there are some cases where this is not true (in particular,
+ generated content containers with overflow clips can be layout roots).
+
+ As in r109406, this patch has no layout test. This is because any test
+ that exercises this behavior is caused by an existing layout bug where
+ a child is not properly getting layout (or a renderer is getting dirtied
+ out of order during layout) and will fail multiple ASSERTs:
+ in particular, ASSERT(!m_layoutRoot->container() || !m_layoutRoot->
+ container()->needsLayout()) in FrameView::scheduleRelayoutOfSubtree(),
+ and ASSERT_NOT_REACHED() in RenderObject::clearLayoutRootIfNeeded().
+ We are preventing those bugs from manifesting as security issues with
+ this patch.
+
+ * rendering/RenderObject.cpp:
+ (WebCore::RenderObject::~RenderObject):
+ (WebCore::RenderObject::willBeDestroyed):
+
2012-05-24 Anders Carlsson <[email protected]>
Corrupted pages rendering when images are zoomed on Google+
Modified: trunk/Source/WebCore/rendering/RenderObject.cpp (118451 => 118452)
--- trunk/Source/WebCore/rendering/RenderObject.cpp 2012-05-25 00:33:06 UTC (rev 118451)
+++ trunk/Source/WebCore/rendering/RenderObject.cpp 2012-05-25 00:46:41 UTC (rev 118452)
@@ -219,7 +219,7 @@
RenderObject::~RenderObject()
{
- ASSERT(!node() || documentBeingDestroyed() || !frame()->view() || frame()->view()->layoutRoot() != this);
+ ASSERT(documentBeingDestroyed() || !frame()->view() || frame()->view()->layoutRoot() != this);
#ifndef NDEBUG
ASSERT(!m_hasAXObject);
renderObjectCounter.decrement();
@@ -2260,7 +2260,7 @@
inline void RenderObject::clearLayoutRootIfNeeded() const
{
- if (node() && !documentBeingDestroyed() && frame()) {
+ if (!documentBeingDestroyed() && frame()) {
if (FrameView* view = frame()->view()) {
if (view->layoutRoot() == this) {
ASSERT_NOT_REACHED();
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
