STR: 1. In about:config, Make sure shumway.disabled=false and shumway.swf.whitelist=http://www.areweflashyet.com/*.swf (or more permissive) (otherwise change these and restart ff) 2 In about:config, dom.mozBrowserFramesEnabled set to false or this setting shall not be present 3. Open http://www.areweflashyet.com/tmp/pac_wmode.html 4. Notice dark-purple background 5. Add boolean or change dom.mozBrowserFramesEnabled to true 6. Open http://www.areweflashyet.com/tmp/pac_wmode.html 7. Notice white background On step 3 and 6 it's using the same markup, but in step 6 the frame opened in separate process. It's expected that background of the iframe will be transparent (or be able to control that via additional e.g. wmode setting). I noticed that when was working on bug 558184, when e.g. http://www.homestarrunner.com/sbemail41.html opened background flicker from white to black while shumway is loading.

Transparent OOP iframe is important for jsplugins like Shumway.

e10s must be disabled to reproduce this bug.

To Markus for a look. How do we alpha-composite in this case?

Jet says Markus is investigating this problem.

The problem here happens before compositing. We get a white background color as the iframe's presshell's mCanvasBackgroundColor, because we hit this case in PresShell::UpdateCanvasBackground(): > if (GetPresContext()->IsCrossProcessRootContentDocument() && > !IsTransparentContainerElement(mPresContext)) { > mCanvasBackgroundColor = > NS_ComposeColors(GetDefaultBackgroundColorToDraw(), mCanvasBackgroundColor); > } IsCrossProcessRootContentDocument() returns true and IsTransparentContainerElement(mPresContext) returns false in our case. IsCrossProcessRootContentDocument() calls TabChild::IsRootContentDocument(), which looks like this: > bool > TabChild::IsRootContentDocument() > { > // A TabChild is a "root content document" if it's > // > // - <iframe mozapp> not inside another <iframe mozapp>, > // - <iframe mozbrowser> (not mozapp), or > // - a vanilla remote frame (<html:iframe remote=true> or <xul:browser > // remote=true>). > // > // Put another way, an iframe is /not/ a "root content document" iff it's a > // mozapp inside a mozapp. (This corresponds exactly to !HasAppOwnerApp.) > // > // Note that we're lying through our teeth here (thus the scare quotes). > // <html:iframe remote=true> or <xul:browser remote=true> inside another > // content iframe is not actually a root content document, but we say it is. > // > // We do this because we make a remote frame opaque iff > // IsRootContentDocument(), and making vanilla remote frames transparent > // breaks our remote reftests. > > return !HasAppOwnerApp(); > } The part of the comment that talks about giving wrong results for remote iframes inside content iframes is exactly the case we're hitting, as far as I understand. So this is probably the code that needs fixing here. For completeness, I also checked what IsTransparentContainerElement(mPresContext) does and why it was introduced. It was added in bug 532569 to support transparent content iframes in the statusbar and in XUL panels, and it checks the "transparent" attribute on those iframes. That check doesn't work in e10s because the iframe element that has the attribute is in another process, so this IsTransparentContainerElement() can't access it.

I wonder who I could ask for advice here. The two people who touched TabChild::IsRootContentDocument() are Chris Jones and Justin Lebar, and they are both no longer around. Maybe "Am I a root content document" needs to be a flag on the TabChild that is supplied to it on creation.

I wonder if this will be the same case for bug 558184 -- the remote frame/tab is created by the jsplugins logic. We can address the issue only there (if adding something to 'iframe' too will not make sense).

Smaug, do you have any thoughts on what we should do here?

Hmm, so we're using mozbrowser here for something else it was designed for. And how does this setup even work in e10s case? We don't support nested oop iframes. (or do we end up using sibling TabChild objects?) But passing some flag when creating TabChild sounds right to me.

Peter, can you take this from here? The jsplugin check probably needs to go one of these three functions: IsCrossProcessRootContentDocument(), IsTransparentContainerElement, or TabChild::IsRootContentDocument().