Title: [190941] releases/WebKitGTK/webkit-2.10
- Revision
- 190941
- Author
- [email protected]
- Date
- 2015-10-13 02:48:06 -0700 (Tue, 13 Oct 2015)
Log Message
Merge r190238 - [GTK] ASSERTION FAILED: !m_inUpdateBackingStoreState in DrawingAreaImpl::display() after DrawingAreaImpl::forceRepaint()
https://bugs.webkit.org/show_bug.cgi?id=148956
Reviewed by Žan Doberšek.
Source/WebKit2:
This is because those tests call notifyDone in the onresize event
handler. InjectedBundlePage::dump() always calls WKBundlePageForceRepaint()
before dumping. When the view is resized DrawingAreaImpl::updateBackingStoreState()
is called, so if the size has changed the FrameView::resize()
method is called and all children are resized, so the onresize
handlers happen at that point, before the
m_inUpdateBackingStoreState is set to false again. For WTR we
could probably just return early from froceReapaint() when
m_inUpdateBackingStoreState is true, because in that case we know
the layout is updated because of the resize and the actual display
is not really needed. But the UI process can also request a force
repaint, so we could wait until the backing store update is done
and then force the repaint. For WTR it will happen after the
dump, but it shouldn't be a problem.
* WebProcess/WebPage/DrawingAreaImpl.cpp:
(WebKit::DrawingAreaImpl::forceRepaint):
(WebKit::DrawingAreaImpl::updateBackingStoreState):
* WebProcess/WebPage/DrawingAreaImpl.h:
LayoutTests:
Unskip tests that should pass now.
* platform/gtk/TestExpectations:
Modified Paths
Diff
Modified: releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog (190940 => 190941)
--- releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog 2015-10-13 09:40:33 UTC (rev 190940)
+++ releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog 2015-10-13 09:48:06 UTC (rev 190941)
@@ -1,3 +1,14 @@
+2015-09-25 Carlos Garcia Campos <[email protected]>
+
+ [GTK] ASSERTION FAILED: !m_inUpdateBackingStoreState in DrawingAreaImpl::display() after DrawingAreaImpl::forceRepaint()
+ https://bugs.webkit.org/show_bug.cgi?id=148956
+
+ Reviewed by Žan Doberšek.
+
+ Unskip tests that should pass now.
+
+ * platform/gtk/TestExpectations:
+
2015-09-23 ChangSeok Oh <[email protected]>
[GTK] playbutton in media controls is not changed when it is clicked.
Modified: releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog (190940 => 190941)
--- releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog 2015-10-13 09:40:33 UTC (rev 190940)
+++ releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog 2015-10-13 09:48:06 UTC (rev 190941)
@@ -1,3 +1,30 @@
+2015-09-25 Carlos Garcia Campos <[email protected]>
+
+ [GTK] ASSERTION FAILED: !m_inUpdateBackingStoreState in DrawingAreaImpl::display() after DrawingAreaImpl::forceRepaint()
+ https://bugs.webkit.org/show_bug.cgi?id=148956
+
+ Reviewed by Žan Doberšek.
+
+ This is because those tests call notifyDone in the onresize event
+ handler. InjectedBundlePage::dump() always calls WKBundlePageForceRepaint()
+ before dumping. When the view is resized DrawingAreaImpl::updateBackingStoreState()
+ is called, so if the size has changed the FrameView::resize()
+ method is called and all children are resized, so the onresize
+ handlers happen at that point, before the
+ m_inUpdateBackingStoreState is set to false again. For WTR we
+ could probably just return early from froceReapaint() when
+ m_inUpdateBackingStoreState is true, because in that case we know
+ the layout is updated because of the resize and the actual display
+ is not really needed. But the UI process can also request a force
+ repaint, so we could wait until the backing store update is done
+ and then force the repaint. For WTR it will happen after the
+ dump, but it shouldn't be a problem.
+
+ * WebProcess/WebPage/DrawingAreaImpl.cpp:
+ (WebKit::DrawingAreaImpl::forceRepaint):
+ (WebKit::DrawingAreaImpl::updateBackingStoreState):
+ * WebProcess/WebPage/DrawingAreaImpl.h:
+
2015-09-22 Tim Horton <[email protected]>
Make it more obvious when using an unaccelerated image buffer, and fix a few callers who do
Modified: releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp (190940 => 190941)
--- releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp 2015-10-13 09:40:33 UTC (rev 190940)
+++ releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp 2015-10-13 09:48:06 UTC (rev 190941)
@@ -197,6 +197,12 @@
void DrawingAreaImpl::forceRepaint()
{
+ if (m_inUpdateBackingStoreState) {
+ m_forceRepaintAfterBackingStoreStateUpdate = true;
+ return;
+ }
+
+ m_forceRepaintAfterBackingStoreStateUpdate = false;
setNeedsDisplay();
m_webPage.layoutIfNeeded();
@@ -375,6 +381,8 @@
}
m_inUpdateBackingStoreState = false;
+ if (m_forceRepaintAfterBackingStoreStateUpdate)
+ forceRepaint();
}
void DrawingAreaImpl::sendDidUpdateBackingStoreState()
Modified: releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.h (190940 => 190941)
--- releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.h 2015-10-13 09:40:33 UTC (rev 190940)
+++ releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.h 2015-10-13 09:48:06 UTC (rev 190941)
@@ -132,6 +132,8 @@
bool m_isPaintingSuspended;
bool m_alwaysUseCompositing;
+ bool m_forceRepaintAfterBackingStoreStateUpdate { false };
+
RunLoop::Timer<DrawingAreaImpl> m_displayTimer;
RunLoop::Timer<DrawingAreaImpl> m_exitCompositingTimer;
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
