We had quite some difficulties with turning all the tests green with 2 content processes enabled, we had to temporarily turn off a few tests in Bug 1301340 as well in the end. Once 2 cp's are enabled on nightly, we want to find a way to turn these tests back on ASAP.

Some of the tests seem to be fixed by the CPOW leak fix, I have not seen them failing on ash at least and has a green try push with them so I start with those.

Pushed by gkrizsanits@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b619d3778de Re-enable some tests. r=me

Pushed by gkrizsanits@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/eaf48c4b002c Re-enable some tests part2. r=me

Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/mozilla-inbound/rev/c01643400ac9 Re-disable browser_referrer_middle_click.js because it fails often with e10s enabled. r=bustage-fix on a CLOSED TREE

Needinfo just to track that browser_referrer_middle_click.js got redisabled because of too many failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/c01643400ac9ac36c470c3e6840df098b3ad3f00

Pushed by kwierso@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0c46a4a90613 redisable browser_referrer_middle_click_in_container.js for failures a=me

Pushed by kwierso@gmail.com: https://hg.mozilla.org/mozilla-central/rev/ece0e0fd16a3 redisable browser_referrer_middle_click_in_container.js for failures a=me

https://hg.mozilla.org/mozilla-central/rev/eaf48c4b002c https://hg.mozilla.org/mozilla-central/rev/c01643400ac9 https://hg.mozilla.org/mozilla-central/rev/ece0e0fd16a3

Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/mozilla-inbound/rev/ca140640db89 Re-disable browser_bug719271.js on Windows debug with e10s for frequent failures. r=bustage-fix

Bug 1301340 forced browser_tabSwitchInPrintPreview.js to run in single-content-process-mode, but I don't see a bug to investigate that and/or remove that workaround, nor any comments in bug 1301340 as to why that was necessary. It's concerning to me that that change was necessary as the test relates to a security issue. Can you clarify if I'm just missing the bug for fixing that test / code properly, or if there isn't one (in which case, please can you file one) ?

(In reply to :Gijs from comment #15) > Bug 1301340 forced browser_tabSwitchInPrintPreview.js to run in > single-content-process-mode, but I don't see a bug to investigate that > and/or remove that workaround, nor any comments in bug 1301340 as to why > that was necessary. It's concerning to me that that change was necessary as > the test relates to a security issue. Can you clarify if I'm just missing > the bug for fixing that test / code properly, or if there isn't one (in > which case, please can you file one) ? I haven't filed a bug for each of these tests, there is one bug where I plan to fix these issues (bug 1301015). Most of the tests that used to fail with multi and timing related are working now, and there are a few tests where the reason for failure is some kind of anti pattern in the tests and in some cases assumptions about multiple tabs end up in the same content process. I went through most of these tests about a month ago and didn't find anything urgent to fix. That being said I'm going to get to it soon after/during the release as soon as I get time for it. The test you're worried about seem to be working fine locally, and if it failed in a scary way I would have investigated it back then at least, so I'm not too concerned, but feel free to try to reenable multi and push it to try, I expect it to work by now as many others on this list.

The leave-open keyword is there and there is no activity for 6 months. :gbrown, maybe it's time to close this bug?

I assume we should keep it open for eventual follow-up on disabled tests.