Lock fission.autostart on beta and release
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
People
(Reporter: mccr8, Assigned: mccr8)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
Fission is not in a good state to enable on beta and release, and there is at least one reason we really don't want anybody to enable it there, so disallow it there by using lockPref.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
I was worried about this causing tests to fail on beta, but Nika said that the way that Fission prefs are enabled for individual tests won't be affected.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
It isn't ready to be enabled yet, and right now it can cause URIs to
be leaked to telemetry.
Assignee | ||
Comment 3•5 years ago
|
||
Comment on attachment 9074572 [details]
Bug 1561950 - Lock fission.autostart on beta and release.
Beta/Release Uplift Approval Request
- User impact if declined: See Bug 1560990.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This simply makes it so that a nonstandard pref setting is ignored. The behavior is pretty broken on 68 anyways, so it isn't likely anybody is going to be using it for much. (This wasn't verified in Nightly, but the patch does not actually change behavior on Nightly, only on Beta and Release. I did a try push with the pref locked, against trunk, and it was okay.)
- String changes made/needed: none
Assignee | ||
Comment 4•5 years ago
|
||
Locally, I checked the behavior of the pref locking without the BETA RELEASE guard. First, I made it so the pref wasn't locked, set the pref to true, and checked that Fission was running. Then I changed all.js to lock the pref, then loaded Firefox and confirmed that the pref was locked and Fission wasn't being used. Then I changed it back, and confirmed that Fission was running again. It looks like there's also various testing of pref locking in the tree.
Comment 6•5 years ago
|
||
bugherder |
Comment 7•5 years ago
|
||
Comment on attachment 9074572 [details]
Bug 1561950 - Lock fission.autostart on beta and release.
Ensures that Fission isn't enabled on 68 even when the pref is manually set. Approved for 68rc1. I do think that we should have QA verify this, however.
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #7)
Ensures that Fission isn't enabled on 68 even when the pref is manually set. Approved for 68rc1. I do think that we should have QA verify this, however.
Seems like a good idea. I'm not sure what the best way to verify it in 68 is. You can easily check that you aren't allowed to set fission.autostart to true in about:config. Maybe that's enough.
Comment 9•5 years ago
|
||
Yeah, I figured just making sure that the pref is non-functional would suffice.
Comment 10•5 years ago
|
||
bugherder uplift |
Comment 11•5 years ago
|
||
This issue is verified fixed using Firefox 68.0 and Firefox 69.0b1 on the following OSes: Windows 10x64, Windows 7x86, mac OS10.14 and Ubuntu 18.04x64
Comment 12•5 years ago
|
||
Retroactively moving fixed bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to an appropriate Fission Milestone.
This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:
0ee3c76a-bc79-4eb2-8d12-05dc0b68e732
Assignee | ||
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Assignee | ||
Updated•5 years ago
|
Updated•4 years ago
|
Description
•