about:gpucrash simulates a GPU process crash. The renderer should recover seamlessly.
Created attachment 104924 [details] Patch
Comment on attachment 104924 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104924&action=review > Source/WebKit/chromium/src/WebViewImpl.cpp:2667 > + // Force ViewHostMsg_DidActivateAcceleratedCompositing to be sent so > + // that the browser process can reacquire surfaces. > + m_isAcceleratedCompositingActive = false; > + setIsAcceleratedCompositingActive(success); why is this different from the previous logic? looks like you broke page overlays here, any particular reason to change that logic too?
Comment on attachment 104924 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104924&action=review >> Source/WebKit/chromium/src/WebViewImpl.cpp:2667 >> + setIsAcceleratedCompositingActive(success); > > why is this different from the previous logic? > > looks like you broke page overlays here, any particular reason to change that logic too? setRootGraphicsLayer was calling setIsAcceleratedCompositingActive, in addition to the stuff that was causing the crash. It looked to me like the page overlay update was redundant, because that is called on line 2628 inside setIsAcceleratedCompositingActive, but that only happens if m_layerTreeHost is null. So you're right, it's still needed here -- I'll add it back in.
Created attachment 104934 [details] Patch
Comment on attachment 104934 [details] Patch Ah, I see. Very subtle. It seems like we've done something wrong with setIsAcceleratedCompositingActive() if we need it do have side effects for true->true transitions. Maybe we need a separate notion of 'toggling compositing on/off' vs 'please update yourself due to some compositing change'. That would be for a different patch, though.
Comment on attachment 104934 [details] Patch Clearing flags on attachment: 104934 Committed r93679: <http://trac.webkit.org/changeset/93679>
All reviewed patches have been landed. Closing bug.