Graduate the toolbar to the main proton pref
Categories
(Firefox :: Toolbars and Customization, task, P2)
Tracking
()
People
(Reporter: mstriemer, Assigned: mstriemer)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-toolbar])
Attachments
(1 file)
We'll want the tests passing first with proton enabled.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c5b7d3456ec9 Graduate toolbar to browser.proton.enabled r=jaws
Comment 3•4 years ago
|
||
Backed out changeset c5b7d3456ec9 (Bug 1696253) for causing bc failures in browser_HomePage_add_button.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/3b63a5eba6751dbb5031145615d94b1c667bcbab
Push with failures, failure log.
Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/819313b50509 Graduate toolbar to browser.proton.enabled r=jaws
Comment 5•4 years ago
|
||
bugherder |
Comment 6•4 years ago
|
||
Given the high rate of failure in bug 1652531, I think either this needs to get backed out or bug 1699614 needs to get landed. Given that we're in soft freeze, backing this out seems like lower risk. Is there some reason this needs to be in 88 instead of 89? If we want people to flip the pref in 88, then we'll want to land bug 1699614 in 88 no matter what, as not having it might cause some crashiness. Any thoughts? I don't know anything about the rollout of Proton for testing or whatever.
Comment 7•4 years ago
•
|
||
(In reply to Andrew McCreight [:mccr8] from comment #6)
Given the high rate of failure in bug 1652531, I think either this needs to get backed out or bug 1699614 needs to get landed. Given that we're in soft freeze, backing this out seems like lower risk. Is there some reason this needs to be in 88 instead of 89? If we want people to flip the pref in 88, then we'll want to land bug 1699614 in 88 no matter what, as not having it might cause some crashiness. Any thoughts? I don't know anything about the rollout of Proton for testing or whatever.
There's a one-time migration that happens as part of proton toolbar work (only if browser.proton.enabled
is flipped) so backing it out isn't very attractive, but we can do it if necessary.
I r+'d your patch in 1699614 just over 4 hours ago though, and just lando'd it before having seen this comment. Is that sufficient here?
Comment 8•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #7)
I r+'d your patch in 1699614 just over 4 hours ago though, and just lando'd it before having seen this comment. Is that sufficient here?
I didn't notice that you'd queued it for landing, thanks. I have no idea how to do a risk assessment to browser.js, but if you are okay with it, that's ok with me.
Comment 9•4 years ago
|
||
Verified that the toolbar is changing as expected with the main proton pref. Tests were performed on Firefox 88.0b3 and Nightly 89.0a1 (2021-03-25) under Windows 10, macOS 10.15.7 and Ubuntu 20.04
Assignee | ||
Updated•4 years ago
|
Description
•