1694257 - Roll-out winning treatment from pin about:welcome experiment

Status: VERIFIED FIXED

(Firefox :: Messaging System, enhancement, P1)

Description

[Ed Lee :Mardak]

There will be an 87 experiment making use of bug 1686343 that we should get initial results early in 87 release that might want to be enabled by default in 88, which could involve uplifting a JSON configuration change early in 88 beta.

To prepare for that, we'll want to make sure the default on experience is working in 88 nightly including decisions like bug 1693736 as well as the ability to only show pinning to the desired windows versions and/or showing if Firefox is not pinned + Firefox can be pinned.

Currently multi-stage about:welcome shows the same screens for all platforms relatively independent of the current state of Firefox (except for theme page which does show the currently selected theme). So we might need some fundamental changes such as smarter targeting of messages/screens. We can still probably assume the primary way someone ends up at about:welcome is from a new installation (vs handling users who manually navigate there).

Comment 1

[Punam Dahiya [:pdahiya]]

With https://bugzilla.mozilla.org/show_bug.cgi?id=1672202, Experiment API uses default values for features such as aboutwelcome.

Discussed briefly with Kate on how we can leverage Nimbus API to have targeted default JSON to show a pin on-boarding default experience to subset of users ( say windows 10 build > 1903)

This has advantage of keeping
a) multiple targeted default at one place in a manifest/config
b) use Nimbus targeting to reach these default JSON
c) re-use schema validations and automated tests
d) In future if we decide to serve these defaults via remote settings , it should be easily extensible

Search feature has similar requirement of targeted defaults to show specific search experience based off targeting such as locale. @mardak do you think this approach will suffice smarter targeting need for Pin as default experience?

Comment 2

[Punam Dahiya [:pdahiya]]

NI Andrei, Kate in bug for feedback on updates in Nimbus API for this requirement

Comment 3

[Andrei Oprea [:andreio]]

Attachment: Bug 1694257 - Add ability for targeted defaults for AboutWelcome

Comment 4

[Punam Dahiya [:pdahiya]]

Attachment: Technical plan for targeted defaults onboarding in Fx88

Comment 5

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Is there a plan to use checkPinCurrentAppToTaskbar() before prompting? This was intended as a check before prompting, to avoid showing the prompt if we know we wouldn't be able to pin (e.g. if Firefox hadn't been installed, the needed API isn't present in some future Windows version, etc).

Comment 6

[Punam Dahiya [:pdahiya]]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #5)

Is there a plan to use checkPinCurrentAppToTaskbar() before prompting? This was intended as a check before prompting, to avoid showing the prompt if we know we wouldn't be able to pin (e.g. if Firefox hadn't been installed, the needed API isn't present in some future Windows version, etc).

That's a good point, we should use checkPinCurrentAppToTaskbar() before returning PinToTaskBar targeted default inside ManifestDefault.jsm.
Is it safe to assume checkPinCurrentAppToTaskbar() is a synchronous call?

Comment 7

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to Punam Dahiya [:pdahiya] from comment #6)

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #5)

Is there a plan to use checkPinCurrentAppToTaskbar() before prompting? This was intended as a check before prompting, to avoid showing the prompt if we know we wouldn't be able to pin (e.g. if Firefox hadn't been installed, the needed API isn't present in some future Windows version, etc).

That's a good point, we should use checkPinCurrentAppToTaskbar() before returning PinToTaskBar targeted default inside ManifestDefault.jsm.
Is it safe to assume checkPinCurrentAppToTaskbar() is a synchronous call?

Yes, it is synchronous, as is pinCurrentAppToTaskbar(). If that's a deal-breaker they could be converted to async using the same method as in isCurrentAppPinnedToTaskbarAsync(), I can pick that up if needed. (Or maybe it's good that it's sync? Don't want to jump to conclusions.)

Comment 8

[Punam Dahiya [:pdahiya]]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #7)

(In reply to Punam Dahiya [:pdahiya] from comment #6)

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #5)

Is there a plan to use checkPinCurrentAppToTaskbar() before prompting? This was intended as a check before prompting, to avoid showing the prompt if we know we wouldn't be able to pin (e.g. if Firefox hadn't been installed, the needed API isn't present in some future Windows version, etc).

That's a good point, we should use checkPinCurrentAppToTaskbar() before returning PinToTaskBar targeted default inside ManifestDefault.jsm.
Is it safe to assume checkPinCurrentAppToTaskbar() is a synchronous call?

Yes, it is synchronous, as is pinCurrentAppToTaskbar(). If that's a deal-breaker they could be converted to async using the same method as in isCurrentAppPinnedToTaskbarAsync(), I can pick that up if needed. (Or maybe it's good that it's sync? Don't want to jump to conclusions.)

The current usage of checkPinCurrentAppToTaskbar in attached patch will need it to be synchronous , so for now we are covered

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96d3adba86e6
Add ability for targeted defaults for AboutWelcome r=k88hudson

Comment 10

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/96d3adba86e6

Comment 11

[Robert Martin [:romartin], Ecosystem QA]

Marking this enhancemend as VERIFIED based on the work done on PI-983.