The "File > Open e10s Window" menu item does not enable shims, so testers are reporting false positive bugs that are actually fixed when shims are enabled by browser.tabs.remote.autostart. I suggested that we just remove the "Open e10s Window" menu item in bug 1003313, but enabling shims all the time is better because shims will get more bake time (before we enable all of e10s) and casual testers can still try per-window e10s. dom.compartment_per_addon (bug 1030420) to land first.

Moving old M2 P2 bugs to M4.

https://tbpl.mozilla.org/?tree=Try&rev=1c5cfe8ad4c9 let's see what breaks test-wise

try looks green to jimm & I. billm?

Comment on attachment 8512087 [details] [diff] [review] enableShimsByDefault OK, let's do this. However, could you please make it nightly-only? The compartment-per-addon stuff is nightly-only, so this should be too.

once more, with ifdefs!

one of the perks of being a night owl today is that the trees are finally open! https://hg.mozilla.org/integration/fx-team/rev/8a1dfdaaeb3c

Not any more, I closed it because someone busted Android. Backed out in https://hg.mozilla.org/integration/fx-team/rev/b0b2b78f2001 for making nearly every test suite on every flavor of Android time out in startup.

(In reply to Phil Ringnalda (:philor) from comment #7) > Not any more, I closed it because someone busted Android. > > Backed out in https://hg.mozilla.org/integration/fx-team/rev/b0b2b78f2001 > for making nearly every test suite on every flavor of Android time out in > startup. Well that didn't last long. Try was green on android too

okay, test ALL THE THINGS remote: You can view the progress of your build at the following URL: remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c3ebccbfbc07 remote: Alternatively, view them on TBPL (soon to be deprecated): remote: https://tbpl.mozilla.org/?tree=Try&rev=c3ebccbfbc07

I wonder if Bug 1091707 is the cause. Try for android is either green or timed out, no failure summmary.

The cause of your backout? No, the problem there was that when automation.py went to start up Fennec, either it never started, or started but never produced whatever it is that automation.py looks for to know that it successfully started the app. The cause of your try run not getting Android builds? No, that's some signing server bustage, which someone should file a bug in Release Engineering about, but instead everyone is just retriggering the builds until they get a successful one.

remote: https://hg.mozilla.org/integration/fx-team/rev/fe00dbf89462

Backed out for that android bustage: https://hg.mozilla.org/integration/fx-team/rev/a31d8d3703f8

version designed to not break android. please note that preprocessor.py does not fully support the macro syntax, so the guards are different in cpp and js.

thanks Tom

remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=48272b5d82c6 remote: Alternatively, view them on TBPL (soon to be deprecated): remote: https://tbpl.mozilla.org/?tree=Try&rev=48272b5d82c6

remote: https://hg.mozilla.org/integration/fx-team/rev/c6d53703d449 since try was green! \o/