Many browser-chrome tests are known to fail when run under e10s. Those tests should be selectively disabled when run with e10s enabled in the hope of seeing green try runs. Note that the attachments in this bug are far from perfect. Running the entire suite still has failures for me - but none of those failures exist when running a subset of the suite. IOW, it's likely more tests will need to be disabled, and also possible there are some "false positives" here. When possible, I've tried to annotate the disabling of each test with a bug number and a description of the problem, but this isn't as consistent as it could be.

This is a rolled up version of the previous patches. It only touches mochitest-browser manifests and disables many tests when run under e10s. It's close to green on try - https://tbpl.mozilla.org/?tree=Try&rev=8636ca4f794d - although billm suggested we should try and get this landed before mopping up the other failures.

Comment on attachment 8398348 [details] [diff] [review] Disable failing tests in e10s Review of attachment 8398348 [details] [diff] [review]: ----------------------------------------------------------------- rs=me, I didn't look at the entire patch, but I skimmed a few files.

Comment on attachment 8398348 [details] [diff] [review] Disable failing tests in e10s >diff --git a/browser/base/content/test/general/browser.ini b/browser/base/content/test/general/browser.ini > [browser_aboutHome.js] >+skip-if = os == "linux" || e10s # Disabled on Linux: Bug 945667; Disabled for e10s: Bug ?????? - no about:home support yet Looks like this got rebased on top of https://hg.mozilla.org/mozilla-central/rev/e8f3be56612d incorrectly - we don't want to disable the entire test on Linux.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #13) > > [browser_aboutHome.js] > >+skip-if = os == "linux" || e10s # Disabled on Linux: Bug 945667; Disabled for e10s: Bug ?????? - no about:home support yet > > Looks like this got rebased on top of > https://hg.mozilla.org/mozilla-central/rev/e8f3be56612d incorrectly - we > don't want to disable the entire test on Linux. Yes - good-catch. Another re-review also found: [browser_dbg_clean-exit-window.js] +# Disabled because of leaks - See Bug 933950. +skip-if = true Pushed with both of them fixed: https://hg.mozilla.org/integration/fx-team/rev/43663582cfdb

Backed out in https://hg.mozilla.org/integration/fx-team/rev/9be5c94051be because it apparently disabled things when e10s isn't defined, too.

(In reply to Phil Ringnalda (:philor) from comment #15) > Backed out in https://hg.mozilla.org/integration/fx-team/rev/9be5c94051be > because it apparently disabled things when e10s isn't defined, too. ++philor for noticing that! Tests aren't being run due to: +++ b/dom/indexedDB/test/browser.ini @@ -1,5 +1,5 @@ [DEFAULT] -run-if = buildapp == "browser" +run-if = buildapp == "browser" && e10s == false No idea yet why that would be.

I think the default value for 'e10s' is None: http://mxr.mozilla.org/mozilla-central/source/testing/mozbase/manifestdestiny/manifestparser/manifestparser.py#230 I think we can use both run-if and skip-if in this case: run-if = buildapp == "browser" skip-if = e10s The way the code works, if either run-if is false or skip-if is true, we disable the test: http://mxr.mozilla.org/mozilla-central/source/testing/mozbase/manifestdestiny/manifestparser/manifestparser.py#1058

(In reply to Bill McCloskey (:billm) from comment #17) > I think the default value for 'e10s' is None: Right - this is being filtered out too early, before we know what the value for 'e10s' should be. This new patch does as you suggest, and I'm carrying r=ted forward. Try at https://tbpl.mozilla.org/?tree=Try&rev=24ff5f15e678 - I'll re-land once try verifies there aren't additional tests being skipped that I missed before.

Of course there was one more "run-if" with the same problem. New try at https://tbpl.mozilla.org/?tree=Try&rev=647835b77ff2, which also includes the patch for bug 979051.

Last try ran all tests https://hg.mozilla.org/integration/mozilla-inbound/rev/b40b275a878d

FYI, this patch accidentally disabled browser_findbar.js on Linux (probably due to a bad merge/rebase) which I just fixed in bug 972684. https://hg.mozilla.org/integration/fx-team/diff/b40b275a878d/toolkit/content/tests/browser/browser.ini#l1.16 I just noticed the same problem with browser_save_private_link_perwindowpb.js: https://hg.mozilla.org/integration/fx-team/diff/b40b275a878d/browser/base/content/test/general/browser.ini#l1.282 I'll file a follow-up