Yury Delendik (:yury) Reporter
	Description • 9 years ago

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.

	Chris Peterson [:cpeterson]
	Comment 2 • 9 years ago

Transparent OOP iframe is important for jsplugins like Shumway.

	Chris Peterson [:cpeterson]
	Comment 3 • 9 years ago

e10s must be disabled to reproduce this bug.

	Jet Villegas (inactive)
	Comment 4 • 9 years ago

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

	Chris Peterson [:cpeterson]
	Comment 5 • 9 years ago

Jet says Markus is investigating this problem.

	Markus Stange [:mstange]
	Comment 6 • 9 years ago

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.

	Markus Stange [:mstange]
	Comment 7 • 9 years ago

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.

	Yury Delendik (:yury) Reporter
	Comment 8 • 9 years ago

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).

	Markus Stange [:mstange]
	Comment 9 • 9 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 10 • 9 years ago

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.

	Markus Stange [:mstange]
	Comment 11 • 9 years ago

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