Not running E10S that I know. I opened http://www.cambridge1.us/about.html, switched to another tab and used Yahoo Mail, went back to the first tab and got the content from Yahoo Mail to show up, flickering. See video.

First, does this need to be security sensitive bug? Seemed scary, so I erred on the side of caution. Second, any ideas where to start with this? Is it graphics, or is it another component? Sorry for the needinfo "spam".

This only sounds like the compositor is confused as to what it should be compositing. Since the compositor's output is not exposed to unprivileged scripts, this doesn't sound like unprivileged scripts could take advantage of this in anyway. Privileged scripts (like reftests!) could conceivably get the pictures. Maybe you could see this bug, then, as a potential vector in a complex exploit: if an attacker knew how to exploit another bug to get chrome privileges, then it might perhaps combine that with the present bug to get confidential data. But that's already very contrived and there are still lots of 'ifs': is this bug triggerable by drawWindow()? Is it reproducible consistently enough to make for a worthwhile attack? As to where to look: This bug looks like the compositor confused about what to composite, which is the subject of layers/compositing IPC, so that's where to start looking. The basic question is: is the bug a bad layer tree, or bad graphics data inside of a good layer tree? To answer that, dump the layer tree on each composite (there's a pref/envvar for that, right?) I'm assuming (I don't remember) that layer tree dumps describe all the way down to Textures. So you should see a difference in the dump, perhaps a wrong Layer, or perhaps a wrong Texture, when the flickering happens. That will tell you where the problem is e.g. if you see a TextureHost pointer jumping to a different value, then look for a IPC bug where we mix up PTexture actors or somesuch. If you still don't see anything, then your next step is likely to add prints in CompositorOGL.cpp...

Note that this same IPC is involved already with one-process OMTC, so it doesn't make a difference whether or not this is using E10s.

Of course, there is the odd chance that this is a bug in the OpenGL driver. However, in past instances where this was the case (which were on MacOSX), we never AFAICR saw such clean rendering of textures from another tab -- we typically saw corrupted textures and/or textures from unrelated processes. And Apple supposedly finally fixed their OpenGL libraries. So at this point, a driver bug seems less likely than a bug on our side.

Without e10s we only have a single layer tree. When layout builds the layers for the new tab, it will discard the layers from the old tab and the ipdl transaction for the paint will do the same for the compositor. It's plausible that this is because we're recycling tiles from the old layers and failing to redraw/reupload the new contents into them. Bug 1077644 suggests that this started within the last week, so a little newer than tiling (3 weeks), but I guess it could be close enough.

Can you reproduce the problem?

I haven't run into it since, and it doesn't reproduce with these sites "on demand". When it happened, http://www.cambridge1.us/about.html didn't display fully, and the bottom half of the background image was blank. Eventually (switching between tabs), it came in, and I only went back to that tab a while later, which is when the bug showed up. The page is not using background property as I first thought, but just a div with an image in it.

If there are no further worries, given comment 2, can I make this non-security bug?

Yes.

Dupe of bug 1067470?