Created attachment 8882520 [details] about:support Video: https://zippy.gfycat.com/GlumNiceKatydid.webm Not 100% sure, but I think it started with yesterday's Nightly 56.0a1 (20170629030206) on Windows 10.
Looks like we just don't draw, so we see the content behind. I see this going back into May 2016: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a884b96685aa13b65601feddb24e5f85ba861561&tochange=c4449eab07d39e20ea315603f1b1863eeed7dcfe
In particular, https://hg.mozilla.org/mozilla-central/rev/9c1eef8037ab
https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindowGfx.cpp#224, or the equivalent in the patch in comment 3 is where it goes south. We had inside the "if": mCompositorBridgeParent->ScheduleRenderOnCompositorThread(); clientLayerManager->Composite(); and changed it to: clientLayerManager->Composite(); In the GPU compositor world, this is now: GetLayerManager()->ScheduleComposite();
David, with compositor bridge parent now being in a different process (potentially) is there a way to cause the equivalent of "CompositorBridgeParent::ScheduleRenderOnCompositorThread" from the nsWindow::OnPaint? I want to try to see if that removes this regression, before deciding what the tradeoffs are and if we should fix it.
(In reply to Milan Sreckovic [:milan] from comment #5) > David, with compositor bridge parent now being in a different process > (potentially) is there a way to cause the equivalent of > "CompositorBridgeParent::ScheduleRenderOnCompositorThread" from the > nsWindow::OnPaint? I want to try to see if that removes this regression, > before deciding what the tradeoffs are and if we should fix it. ScheduleRenderOnCompositorThread posts a task to the compositor thread, which then schedules a composition for the next vsync. In theory ScheduleComposite does the exact same thing, except it goes over IPC instead . That is a change in timing though, since messages over threads will get processed faster. You could disable the GPU process, and then call ScheduleRenderOnCompositorThread as before. The widget has a mCompositorSession, which has a GetCompositorBridgeChild() method.  http://searchfox.org/mozilla-central/source/gfx/layers/ipc/ShadowLayers.cpp#910  http://searchfox.org/mozilla-central/rev/f1472e5b57fea8d4a7bbdd81c44e46958fe3c1ce/gfx/layers/ipc/CompositorBridgeParent.cpp#1274
I'll give that a try, but I imagine it would take care of the problem, given that this regression precedes the GPU process work. If there are performance implications though, I'd probably just wontfix this bug - the user just happens to see what's behind, but it isn't like we're leaking that information *to* Firefox.
FWIW I see the same thing when I do this with other Windows apps.
Me too, tested with Store, Mail and Groove Music on Windows 10.
Priority: -- → P3
For some reason I'm not able to reproduce this anymore since the latest 2 Nightlies (maybe even more, but these are the ones I tested)...
I still see it on 20170915100121
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox57: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.