The browser_aboutwelcome_multistage test is incompatible with Proton pref removed
Categories
(Firefox :: Messaging System, task, P3)
Tracking
()
People
(Reporter: masterwayz, Assigned: Mardak)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-onboarding])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
From https://searchfox.org/mozilla-central/source/browser/components/newtab/test/browser/browser_aboutwelcome_multistage.js#311 it looks like Proton gets disabled as otherwise the test does not work. However, we are currently working on removing the proton pref, the first stage of this is Bug 1711497.
NI'ing :Mardak to see if he has more info and what should be done.
Assignee | ||
Comment 1•3 years ago
|
||
I believe we want to be able to run experiments with the pre-proton designs even after mr1 ships. There is a way to turn off the proton about:welcome styles by enrolling in a fake experiment with isProton: false
similar to this:
https://searchfox.org/mozilla-central/rev/443f87caa5fadba920b0382e12874693d6c6133a/browser/components/newtab/test/browser/browser_aboutwelcome_multistage.js#496,502
There are some tests/add_task that already use ExperimentFakes.enrollWithFeatureConfig
so that should be just updating those to isProton: false
but some later tests in that file just use defaults relying on fallbackPref
feature manifest behavior.
pdahiya, should we be switching the non-experimentAPI tests to assume isProton: true? Maybe as part of bug 1709720 ?
Comment 2•3 years ago
|
||
Ed, is the only way in which this pref flip influences behaviour of nightly through the experiment's isProton
flag? That is, if the pref existed but we removed all code that directly read the pref in Firefox, would the test still pass?
I'm asking because I was sort of hoping to get all the non-proton behaviour that depends on the prefs out of central in the 90 cycle still... (see https://docs.google.com/document/d/1M_OPsYyIzdyzcP2J7TJAsLMdAUlPS7h2J_AxSAxysqA/edit# ) but it sounds like if we left the pref but removed all the code that honoured the pref directly, the test would still pass because the about:welcome code honours the isProton
thing that reflects the pref if the experiment has no other indication. So perhaps we could just leave this for now... Is that right?
Assignee | ||
Comment 3•3 years ago
|
||
As in the rest of Firefox would no longer follow browser.proton.enabled
but it would be around only to be used by about:welcome (via NimbusFeatures.aboutwelcome.getValue().isProton
)? That should work.
Alternatively without changing too much, we could basically undo bug 1704571 and "ungraduate" back to a dedicated new pref, e.g., browser.aboutwelcome.protonDesign
https://hg.mozilla.org/mozilla-central/rev/9af627d3621212f5af1a2f9874c6eff2ea6b9e57
Assignee | ||
Comment 4•3 years ago
|
||
Restore the design pref but as a bool just for proton.
Assignee | ||
Comment 5•3 years ago
|
||
Sounds like we will keep the pre-proton design for at least until we get results from the 89 holdback experiment bug 1709718, which at earliest would be during 91 nightly cycle. So either way keeping the existing proton.enabled or a new aboutwelcome.protonDesign pref should be pretty temporary.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
We'll have a separate pref so we can better control when we get rid of the old design while making it easier to toggle.
Updated•3 years ago
|
Comment 8•3 years ago
|
||
bugherder |
Comment 9•3 years ago
|
||
I have verified this task and I can confirm the the browser.aboutwelcome.protonDesign
pref with the value set to true
by default is displayed in the "about:config" page.
Verified using the latest Firefox Beta (90.0b5 Build ID - 20210608185546) installed on Windows 10 x64, macOS 10.15.7, and Linux Mint 20 x64.
Description
•