http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChild.js?rev=9bf6ffacf4f6&mark=55-55#55 shows up in the profiles since it causes child process to just wait for parent. We could, I think, just send the name when creating the child.

We need both fullscreenAllowed very early to let apps go fullscreen or not too.

We could just set name and fullscreenallowed when creating a mozbrowser. Parent would send that info during creation.

Hmm, we may run BrowserElementChild.js in the same process as *Parent

Boo, we have also the preload mechanism making this all more complicated.

It's mostly green on try (https://tbpl.mozilla.org/?tree=Try&rev=0b49b62a014d) but not fully yet...

s/NS_LITERAL_STRING("")/EmptyString()/

Comment on attachment 8507472 [details] [diff] [review] no-sync-hello.patch Don't you need to have some special case for FakeShow

But yes, the approach looks good to me.

Still one test failure (M5 emulator opt only :( ) where we get a visibilitychange event earlier than expected. https://tbpl.mozilla.org/?tree=Try&rev=4422f4aa98c4

Rebased. Try run is at https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=dec35a628939 There are 2 real failures (Gip f2 and N2 in emulator opt) that are both related to visibilitychange issues. For the M2 failure (that I can't repro locally of course...) we get the visibilitychange event before the onload one in https://mxr.mozilla.org/mozilla-central/source/dom/browser-element/mochitest/file_browserElement_SetVisibleFrames_Inner.html?force=1 I'm not sure if that actually a bug or not. Olli, what do you think?

load event doesn't have anything to do with visibility so, so yes, visibilitychange may easily happen before load.

Works fine, green run at https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=ec645029389c The test change is there to not expect anymore than we get onload before onvisibility change.

Comment on attachment 8529463 [details] [diff] [review] patch v4 >+ mDocShell->SetFullscreenAllowed( >+ mOwnerContent->HasAttr(kNameSpaceID_None, nsGkAtoms::allowfullscreen) || >+ mOwnerContent->HasAttr(kNameSpaceID_None, nsGkAtoms::mozallowfullscreen)); >+ bool isPrivate = mOwnerContent->HasAttr(kNameSpaceID_None, nsGkAtoms::mozprivatebrowsing); >+ if (isPrivate) { >+ bool nonBlank; >+ mDocShell->GetHasLoadedNonBlankURI(&nonBlank); >+ if (nonBlank) { >+ printf_stderr("We should not switch to Private Browsing after loading a document.\n"); this is a bit odd. Report to console? >- else { >+ /*else { > // Pass the message up to our parent. > alert(e.detail.message); >- } >+ }*/ I don't understand this. Please explain. And either remove the code, or remove /* and */ >+struct ShowInfo >+{ >+ nsString name; >+ bool fullscreenAllowed; >+ bool isPrivate; a ctor would be good here. It would initialize both bool variables to false. >+ ShowInfo info(EmptyString(), true, false); and then you could just have ShowInfo info; here. (I don't understand why you have true for fullscreenAllowed here. Looks wrong)

(In reply to Olli Pettay [:smaug] from comment #14) > Comment on attachment 8529463 [details] [diff] [review] > >+ if (nonBlank) { > >+ printf_stderr("We should not switch to Private Browsing after loading a document.\n"); > this is a bit odd. > Report to console? Done, using nsContentUtils::ReportToConsoleNonLocalized() > >- else { > >+ /*else { > > // Pass the message up to our parent. > > alert(e.detail.message); > >- } > >+ }*/ > > I don't understand this. Please explain. > And either remove the code, or remove /* and */ This is to fix the issue explained in comment 11 : we get a visibility change event before onload on emulator, and that makes the test fail because we relay an unexpected event. > >+struct ShowInfo > >+{ > >+ nsString name; > >+ bool fullscreenAllowed; > >+ bool isPrivate; > > a ctor would be good here. > It would initialize both bool variables to false. This is a ipdl struct, which is codegene'd. I didn't find a way to add a constructor by annotating the ipdl. Let me know if there's a way! > (I don't understand why you have true for fullscreenAllowed here. Looks > wrong) Fixed, and I verified with fullscreen apps that everything works properly.

Comment on attachment 8530472 [details] [diff] [review] patch v5 >+TabChild::ApplyShowInfo(const ShowInfo& info) aInfo ditto elsewhere for params.

sorry backed out for bustage like https://treeherder.mozilla.org/ui/logviewer.html#?job_id=941014&repo=b2g-inbound