enable e10s by default on Nightly (only)

VERIFIED FIXED in mozilla36

Status

()

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: mossop, Assigned: Felipe)

Tracking

unspecified
mozilla36
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(e10sm4+)

Details

Attachments

(5 attachments, 3 obsolete attachments)

Add a new opt in pref along the lines of bug 1058358 comment 1 to enable e10s by default on nightly only.
(Reporter)

Updated

5 years ago
Assignee: nobody → felipc
(Reporter)

Comment 1

5 years ago
Can you give this a points estimate felipe?
Status: NEW → ASSIGNED
Iteration: --- → 36.2
Flags: qe-verify?
Flags: firefox-backlog+
Flags: needinfo?(felipc)
(Assignee)

Comment 2

5 years ago
In bug 1058358, besides discussions of going with something simpler, we ended up implementing the proposal from comment 1. So there might not be much needed here besides defining the pref. But I'll ask around on IRC to see if people had other stuff in mind.
(Assignee)

Updated

5 years ago
Points: --- → 1
Flags: qe-verify?
Flags: qe-verify+
Flags: needinfo?(felipc)
Summary: Add a new pref to enable e10s by default → enable e10s by default on Nightly
(Assignee)

Comment 3

5 years ago
We need to make sure that the test suites are not affected by this change, because the tests that are e10s-ready are already running through special configurations that set e10s = true.

MozMill was already handled in bug 1081996 but mostly everything else will need it. I'll put up the patches for them
(Assignee)

Comment 4

5 years ago
Posted patch Patch for talos (obsolete) — Splinter Review
Attachment #8516899 - Flags: review?(jmaher)
(Assignee)

Comment 5

5 years ago
Posted patch talose10sSplinter Review
new patch for talos, after talking about it with jmaher
Attachment #8516899 - Attachment is obsolete: true
Attachment #8516899 - Flags: review?(jmaher)
Attachment #8516918 - Flags: review?(jmaher)
Comment on attachment 8516918 [details] [diff] [review]
talose10s

Review of attachment 8516918 [details] [diff] [review]:
-----------------------------------------------------------------

yay, please land this!
Attachment #8516918 - Flags: review?(jmaher) → review+
(Assignee)

Comment 7

5 years ago
Posted patch Marionette (obsolete) — Splinter Review
Don't let the autostart.N prefs affect Marionette runs
Attachment #8516928 - Flags: review?(cmanchester)
(Assignee)

Updated

5 years ago
Attachment #8516918 - Flags: checkin+
Attachment #8516928 - Flags: review?(cmanchester) → review+
Attachment #8516928 - Flags: review+ → review-
Comment on attachment 8516928 [details] [diff] [review]
Marionette

Review of attachment 8516928 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/marionette/client/marionette/geckoinstance.py
@@ +27,5 @@
>                        "browser.displayedE10SPrompt.2": 5,
>                        "browser.displayedE10SPrompt.3": 5,
> +                      "browser.displayedE10SPrompt.4": 5,
> +                      "browser.tabs.remote.autostart.1": False,
> +                      "browser.tabs.remote.autostart.2", False}

Sorry, just noticed the typo: s/,/:/
(Assignee)

Comment 10

5 years ago
Posted patch MarionetteSplinter Review
Bah!
Attachment #8516928 - Attachment is obsolete: true
Attachment #8516939 - Flags: review?(cmanchester)
(Assignee)

Comment 11

5 years ago
I'll send all of this through try before landing
Attachment #8516940 - Flags: review?(jmaher)
Comment on attachment 8516940 [details] [diff] [review]
Talos revision

Review of attachment 8516940 [details] [diff] [review]:
-----------------------------------------------------------------

just wait until you see something show up green on try first :)
Attachment #8516940 - Flags: review?(jmaher) → review+
Attachment #8516939 - Flags: review?(cmanchester) → review+
Some clarity for anyone who might stumble upon this bug without other context: we're not expecting this to ride the trains.
(Assignee)

Comment 15

5 years ago
This doesn't block the M-e10s tests to properly run, which will continue to use browser.tabs.remote.autostart
Attachment #8517121 - Flags: review?(gavin.sharp)
(Assignee)

Comment 16

5 years ago
Let's see if there are any tests configurations missing. This try build includes all patches from here:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=bc5452c26d82
https://tbpl.mozilla.org/?tree=Try&rev=bc5452c26d82
Attachment #8517119 - Flags: review?(gavin.sharp) → review+
Attachment #8517121 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 17

5 years ago
From the try run in comment 16, the only remaining harness affected is the Linux-Mulet Reftest. I pushed a new patch to try that should fix that:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=cf2a4e06c146
https://tbpl.mozilla.org/?tree=Try&rev=cf2a4e06c146
(Assignee)

Comment 18

5 years ago
Attachment #8517201 - Flags: review?(armenzg)

Comment 19

5 years ago
Comment on attachment 8517201 [details] [diff] [review]
Safeguard Mulet-Reftest from e10s-on-nightly pref

I don't think I can review this patch as I don't know what it can affect (I think only affects b2g desktop and mulet jobs, however, I'm not sure).

If you want to only affect Linux mulet tests you can use:
"if options.mulet"

Right now we can't get results for mulet reftests since they're checking for updates and that causes to hit the network which we block:
https://bugzilla.mozilla.org/show_bug.cgi?id=1043699#c100

You can try the patch with this workaround which removes the block on the network:
https://hg.mozilla.org/try/rev/be3fb02d83bd
Attachment #8517201 - Flags: review?(armenzg)

Comment 20

5 years ago
FYI Mulet reftests are not tier-1, the jobs were shown visibly on the Try tree for 1 day or two by mistake.

I hope that helps!
(Assignee)

Comment 21

5 years ago
(In reply to Armen Zambrano - Automation & Tools Engineer (:armenzg) from comment #20)
> FYI Mulet reftests are not tier-1, the jobs were shown visibly on the Try
> tree for 1 day or two by mistake.
> 
> I hope that helps!

Ah ok! It definitely helps. I see other pushes to try and they are equally red, so maybe it's not even due to this change. In any case, we don't need to make Linux-mulet green here to land these
(Assignee)

Updated

5 years ago
Attachment #8517201 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Attachment #8516939 - Flags: checkin+
(Assignee)

Updated

5 years ago
Attachment #8516940 - Flags: checkin+
(Assignee)

Updated

5 years ago
Attachment #8517121 - Flags: checkin+
Depends on: 1095012
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #13)
> Some clarity for anyone who might stumble upon this bug without other
> context: we're not expecting this to ride the trains.
Summary: enable e10s by default on Nightly → enable e10s by default on Nightly (only)
https://hg.mozilla.org/mozilla-central/rev/a75897e664dd
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36

Updated

5 years ago
Depends on: 1095455

Updated

5 years ago
No longer depends on: 1095455
I confirm that e10s is enabled by default on Nightly 36.0a1 (2014-11-13) using Windows 8.1 x64, Ubuntu 14.04 x32 and Max OSx 10.8.5.
Status: RESOLVED → VERIFIED
Depends on: 1130435

Updated

4 years ago
Depends on: 1160058

Updated

4 years ago
Depends on: 1193088
You need to log in before you can comment on or make changes to this bug.