Closed Bug 1694257 Opened 9 months ago Closed 9 months ago

Roll-out winning treatment from pin about:welcome experiment

Categories

(Firefox :: Messaging System, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
88 Branch
Iteration:
88.2 - Mar 8 - Mar 21
Tracking Status
firefox88 --- verified

People

(Reporter: Mardak, Assigned: andreio)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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).

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?

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

Flags: needinfo?(khudson)
Flags: needinfo?(andrei.br92)
Blocks: 1694408
Flags: needinfo?(khudson)
Depends on: 1694578
Assignee: nobody → andrei.br92
Flags: needinfo?(andrei.br92)
Severity: -- → S3
Iteration: --- → 88.1 - Feb 22 - Mar 7
Priority: -- → P1

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).

(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?

Flags: needinfo?(agashlin)

(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.)

Flags: needinfo?(agashlin)

(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

Iteration: 88.1 - Feb 22 - Mar 7 → 88.2 - Mar 8 - Mar 21
Attachment #9205355 - Attachment description: Bug 1694257 - WIP: Roll-out winning treatment from pin about:welcome experiment → Bug 1694257 - Add ability for targeted defaults for AboutWelcome
Pushed by aoprea@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/96d3adba86e6
Add ability for targeted defaults for AboutWelcome r=k88hudson
Blocks: 1698962
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Blocks: 1699237

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

Status: RESOLVED → VERIFIED
See Also: → 1711700
You need to log in before you can comment on or make changes to this bug.