Title: [182807] trunk/Source/WebCore
- Revision
- 182807
- Author
- cdu...@apple.com
- Date
- 2015-04-14 13:54:36 -0700 (Tue, 14 Apr 2015)
Log Message
ASSERT(frame().view() == this) assertion hit in FrameView::windowClipRect() on Windows bots
https://bugs.webkit.org/show_bug.cgi?id=143723
Reviewed by Brent Fulgham.
ASSERT(frame().view() == this) in FrameView::windowClipRect() can be hit
if the post layout timer timer fires after the page has entered page
cache. Upon entering page cache, we call FrameView::unscheduleRelayout()
to stop the layout timer if it is active, however, we don't stop the
post-layout timer. Therefore, there was nothing preventing the
post-layout timer from firing after entering page cache.
In this patch, we unschedule the post-layout timer in
FrameView::unscheduleRelayout() to protect ourselves against this.
I think we were only seeing the assertion hit on Windows because this
timer probably gets scheduled more frequently on Windows. On Mac, I
rarely see it getting scheduled.
No new tests, should fix crashing tests on the bots.
* page/FrameView.cpp:
(WebCore::FrameView::unscheduleRelayout):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (182806 => 182807)
--- trunk/Source/WebCore/ChangeLog 2015-04-14 19:35:32 UTC (rev 182806)
+++ trunk/Source/WebCore/ChangeLog 2015-04-14 20:54:36 UTC (rev 182807)
@@ -1,5 +1,31 @@
2015-04-14 Chris Dumez <cdu...@apple.com>
+ ASSERT(frame().view() == this) assertion hit in FrameView::windowClipRect() on Windows bots
+ https://bugs.webkit.org/show_bug.cgi?id=143723
+
+ Reviewed by Brent Fulgham.
+
+ ASSERT(frame().view() == this) in FrameView::windowClipRect() can be hit
+ if the post layout timer timer fires after the page has entered page
+ cache. Upon entering page cache, we call FrameView::unscheduleRelayout()
+ to stop the layout timer if it is active, however, we don't stop the
+ post-layout timer. Therefore, there was nothing preventing the
+ post-layout timer from firing after entering page cache.
+
+ In this patch, we unschedule the post-layout timer in
+ FrameView::unscheduleRelayout() to protect ourselves against this.
+
+ I think we were only seeing the assertion hit on Windows because this
+ timer probably gets scheduled more frequently on Windows. On Mac, I
+ rarely see it getting scheduled.
+
+ No new tests, should fix crashing tests on the bots.
+
+ * page/FrameView.cpp:
+ (WebCore::FrameView::unscheduleRelayout):
+
+2015-04-14 Chris Dumez <cdu...@apple.com>
+
FrameView::m_frame should be a Ref<Frame>
https://bugs.webkit.org/show_bug.cgi?id=143716
Modified: trunk/Source/WebCore/page/FrameView.cpp (182806 => 182807)
--- trunk/Source/WebCore/page/FrameView.cpp 2015-04-14 19:35:32 UTC (rev 182806)
+++ trunk/Source/WebCore/page/FrameView.cpp 2015-04-14 20:54:36 UTC (rev 182807)
@@ -2620,6 +2620,9 @@
void FrameView::unscheduleRelayout()
{
+ if (m_postLayoutTasksTimer.isActive())
+ m_postLayoutTasksTimer.stop();
+
if (!m_layoutTimer.isActive())
return;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
