1711942 - The browser_aboutwelcome_multistage test is incompatible with Proton pref removed

Status: VERIFIED FIXED

(Firefox :: Messaging System, task, P3)

Description

[Michelle Goossens [:masterwayz]]

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.

Comment 1

[Ed Lee :Mardak]

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

[:Gijs (he/him)]

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?

Comment 3

[Ed Lee :Mardak]

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

See attachment 9222709 [details]

Comment 4

[Ed Lee :Mardak]

Attachment: Bug 1711942 - Ungraduate about:welcome from proton pref

Restore the design pref but as a bool just for proton.

Comment 5

[Ed Lee :Mardak]

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.

Comment 6

[Ed Lee :Mardak]

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.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc854621958d
Ungraduate about:welcome from proton pref r=pdahiya

Comment 8

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/cc854621958d

Comment 9

[Marius Coman [:mcoman], Ecosystem QA]

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.