977891 - [e10s] Painting stops happening on certain web pages

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I haven't figured out the circumstances, but several people have seen this problem. On certain web sites (possibly those with plugins or with lots of images), we stop painting except when you move the mouse outside of the content area. I've seen this happen on http://typesetinthefuture.com/moon/, but Tom can't reproduce it there. It only happen in e10s, so I don't think it's purely an OMTC problem. If you switch to a different tab, painting works fine.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

OK, it's definitely plugin-related. It only happens on the page I mentioned when Flash is enabled.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: plugin-paint-hack

This is the line that's causing the problem. If I comment it out, everything works fine. Matt, any advice about what to do?

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

In case it's important, we're running Flash in windowless mode in e10s.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think the problem might be that this code:
http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/ClientLayerManager.cpp#260
isn't doing anything because GetRemoteRenderer() is null. I tried setting it to the right CompositorChild, but that's not working for some reason.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Ah, this is my fault :(

The problem is that the receiving end of that message (CrossProcessCompositorChild::RecvForceComposite) does nothing. And it can't really do anything, since the PCompositor connection is a singleton per child process, and we don't know which LayerTree we're operating on.

The ForceComposite ipdl message should be moved to PLayerTransaction instead, since that always lets us map a ClientLayerManager to a CompositorParent (the root one, not CrossProcessCP). 'ShadowLayersUpdated' is an exmaple of this.

Comment 6

[Matt Woodrow (:mattwoodrow)]

Attachment: Fix ForceComposite message for e10s

This should no longer discriminate against e10s child processes, but I haven't actually tested it. It builds!

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8383483 [details] [diff] [review]
Fix ForceComposite message for e10s

Review of attachment 8383483 [details] [diff] [review]:
-----------------------------------------------------------------

Works great, thanks!

Comment 8

[Nicolas Silva [:nical]]

Comment on attachment 8383483 [details] [diff] [review]
Fix ForceComposite message for e10s

Review of attachment 8383483 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/ipc/PLayerTransaction.ipdl
@@ +84,5 @@
>  
>    // Drop any front buffers that might be retained on the compositor
>    // side.
>    async ClearCachedResources();
> +  

nit: trailing space

Comment 9

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f57a742a1273

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f57a742a1273