Title: [149208] trunk/Source/WebKit2
- Revision
- 149208
- Author
- simon.fra...@apple.com
- Date
- 2013-04-26 14:13:22 -0700 (Fri, 26 Apr 2013)
Log Message
Inspector window is often blank when opened
https://bugs.webkit.org/show_bug.cgi?id=115220
<rdar://problem/13735496>
Reviewed by Tim Horton.
After disabling tiled scrolling and accelerated drawing in r149006, the
Inspector window was often missing its content after opening. This only
happened when the user has a preference on disk to use accelerated drawing
in the Inspector.
The missing content was caused by a failure to connect the correct contextID
for remote layer hosting. On window creation, we hook up a context using
WindowServer layer hosting (the default), but then switch back to app-hosted
layers for the Inspector window. This switching happens in didUpdateBackingStoreState(),
but that can be re-entered via its call to sendUpdateBackingStoreState(). In
that cause, on unwinding the stack it would call enterAcceleratedCompositingMode()
with a stale layerTreeContext.
Fix by moving the code that exits/enters accelerated compositing mode to before
the call to sendUpdateBackingStoreState() that can cause re-entrancy. That avoids
use of a possibly stale layerTreeContext.
* UIProcess/DrawingAreaProxyImpl.cpp:
(WebKit::DrawingAreaProxyImpl::didUpdateBackingStoreState):
Modified Paths
Diff
Modified: trunk/Source/WebKit2/ChangeLog (149207 => 149208)
--- trunk/Source/WebKit2/ChangeLog 2013-04-26 21:13:19 UTC (rev 149207)
+++ trunk/Source/WebKit2/ChangeLog 2013-04-26 21:13:22 UTC (rev 149208)
@@ -1,3 +1,30 @@
+2013-04-26 Simon Fraser <simon.fra...@apple.com>
+
+ Inspector window is often blank when opened
+ https://bugs.webkit.org/show_bug.cgi?id=115220
+
+ Reviewed by Tim Horton.
+
+ After disabling tiled scrolling and accelerated drawing in r149006, the
+ Inspector window was often missing its content after opening. This only
+ happened when the user has a preference on disk to use accelerated drawing
+ in the Inspector.
+
+ The missing content was caused by a failure to connect the correct contextID
+ for remote layer hosting. On window creation, we hook up a context using
+ WindowServer layer hosting (the default), but then switch back to app-hosted
+ layers for the Inspector window. This switching happens in didUpdateBackingStoreState(),
+ but that can be re-entered via its call to sendUpdateBackingStoreState(). In
+ that cause, on unwinding the stack it would call enterAcceleratedCompositingMode()
+ with a stale layerTreeContext.
+
+ Fix by moving the code that exits/enters accelerated compositing mode to before
+ the call to sendUpdateBackingStoreState() that can cause re-entrancy. That avoids
+ use of a possibly stale layerTreeContext.
+
+ * UIProcess/DrawingAreaProxyImpl.cpp:
+ (WebKit::DrawingAreaProxyImpl::didUpdateBackingStoreState):
+
2013-04-26 Alexey Proskuryakov <a...@apple.com>
Crashes under ResourceHandle::continueDidReceiveResponse when loading blobs
Modified: trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp (149207 => 149208)
--- trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp 2013-04-26 21:13:19 UTC (rev 149207)
+++ trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp 2013-04-26 21:13:22 UTC (rev 149208)
@@ -193,11 +193,6 @@
// Stop the responsiveness timer that was started in sendUpdateBackingStoreState.
m_webPageProxy->process()->responsivenessTimer()->stop();
- if (m_nextBackingStoreStateID != m_currentBackingStoreStateID)
- sendUpdateBackingStoreState(RespondImmediately);
- else
- m_hasReceivedFirstUpdate = true;
-
#if USE(ACCELERATED_COMPOSITING)
if (layerTreeContext != m_layerTreeContext) {
if (!m_layerTreeContext.isEmpty()) {
@@ -210,7 +205,14 @@
ASSERT(layerTreeContext == m_layerTreeContext);
}
}
+#endif
+ if (m_nextBackingStoreStateID != m_currentBackingStoreStateID)
+ sendUpdateBackingStoreState(RespondImmediately);
+ else
+ m_hasReceivedFirstUpdate = true;
+
+#if USE(ACCELERATED_COMPOSITING)
if (isInAcceleratedCompositingMode()) {
ASSERT(!m_backingStore);
return;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
