Closed
Bug 1156613
Opened 9 years ago
Closed 9 years ago
Fix e10s blocks conditioned to NIGHTLY_BUILD (and others) in preparation for Aurora merge
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
People
(Reporter: Felipe, Assigned: Felipe)
Details
Attachments
(4 files, 1 obsolete file)
1.20 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
4.12 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
1.77 KB,
patch
|
Details | Diff | Splinter Review | |
1.68 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
There are some parts of the code related to e10s that might be tied to #ifdef NIGHTLY_BUILDS (or similar) blocks and will break when we make the move to Aurora. We need to find out these cases and ensure they work correctly on Aurora. There's also E10S_TESTING_ONLY which is currently tied to NIGHTLY_BUILD. It would be good if at least some of the simple cases for these are fixed to do the proper checks of window/browser remoteness instead of the ifdefs. At a minimum, before the uplift we must: - find out blocks tied to nightly and make them tied to E10S_TESTING_ONLY - define E10S_TESTING_ONLY for Aurora But it would be nice to do a little better than that, at least for a subset of this, depending on the cost/benefit of the change Something similar was already done one year ago in bug 1016834 but it's likely that in the meantime more cases showed up.
Assignee | ||
Comment 1•9 years ago
|
||
I'm already taking this on the assumption that this will be marked as an m6
Assignee: nobody → felipc
Status: NEW → ASSIGNED
Updated•9 years ago
|
Flags: qe-verify-
Flags: firefox-backlog+
Updated•9 years ago
|
Iteration: --- → 40.2 - 27 Apr
Updated•9 years ago
|
Assignee | ||
Updated•9 years ago
|
Points: --- → 3
Flags: needinfo?(felipc)
Assignee | ||
Comment 3•9 years ago
|
||
Attachment #8596616 -
Flags: review?(wmccloskey)
Assignee | ||
Comment 4•9 years ago
|
||
Attachment #8596617 -
Flags: review?(wmccloskey)
Assignee | ||
Comment 5•9 years ago
|
||
Paolo, this came from bug 1021172. With e10s on Aurora, we need to fix this #ifdef'ed blocks. Is there any reason not to simply remove the ifdef and let this code be always on, even when e10s is off (e.g. after riding the trains, on Beta/Release)?
Attachment #8596621 -
Flags: review?(paolo.mozmail)
Attachment #8596616 -
Flags: review?(wmccloskey) → review+
Attachment #8596617 -
Flags: review?(wmccloskey) → review+
Comment 6•9 years ago
|
||
Comment on attachment 8596621 [details] [diff] [review] requestAutoComplete The entire feature is currently meant to be enabled in Nightly only, so I think there is nothing to do here. Thanks for taking a look!
Attachment #8596621 -
Flags: review?(paolo.mozmail)
Assignee | ||
Comment 7•9 years ago
|
||
Bill: by looking at bug 1133099 I assume we don't need to carry https://mxr.mozilla.org/mozilla-central/source/dom/webidl/Navigator.webidl?rev=a6eac2cc6ba7#433 to Aurora, right? And also bug 1069704?
Flags: needinfo?(wmccloskey)
Assignee | ||
Comment 8•9 years ago
|
||
Do you want addon-watcher and/or compartment-per-addon in Aurora? And do you know about the async plugin initilization?
Attachment #8598223 -
Flags: review?(wmccloskey)
Luke, what do we want to do about bug 1133099 once e10s goes to Aurora? We've fixed pointer locking and bug 1144906 is a blocker for us going to Aurora. Is that sufficient to say we don't need this flag anymore?
Flags: needinfo?(wmccloskey) → needinfo?(luke)
Aaron, what are we going to do with async plugin init once e10s goes to Aurora? We anticipate that FF40 will have e10s enabled when it's on Aurora and then we'll disable e10s when it goes to beta.
Flags: needinfo?(aklotz)
Yoric, same question as above: what will we do about the addon-watcher code when e10s goes to Aurora?
Flags: needinfo?(dteller)
Comment 12•9 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #9) Yes, with those fixed, I don't know of any need for that property.
Flags: needinfo?(luke)
Updated•9 years ago
|
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
Assignee | ||
Comment 13•9 years ago
|
||
So what I talked with Aklotz is that I'll change the ifdef for correctness sake (in order to fix this bug and in case the async plugin work takes longer), but he will most likely remove the ifdef altogether before the merge with bug 1145838. The addon-watcher I'd like to leave untouched here and left to its own bug, because I think it makes sense to wait a few days of things running smoothly in Aurora before enabling it. But that discussion can happen elsewhere.
Attachment #8598223 -
Attachment is obsolete: true
Attachment #8598223 -
Flags: review?(wmccloskey)
Flags: needinfo?(dteller)
Flags: needinfo?(aklotz)
Attachment #8600038 -
Flags: review?(wmccloskey)
Attachment #8600038 -
Flags: review?(wmccloskey) → review+
Comment 15•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2357d7d9c25e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 40
You need to log in
before you can comment on or make changes to this bug.
Description
•