Roll-out winning treatment from pin about:welcome experiment
Categories
(Firefox :: Messaging System, enhancement, P1)
Tracking
()
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).
Comment 1•4 years ago
•
|
||
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•4 years ago
|
||
NI Andrei, Kate in bug for feedback on updates in Nimbus API for this requirement
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
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•4 years ago
|
||
(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•4 years ago
|
||
(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•4 years ago
|
||
(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
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
Marking this enhancemend as VERIFIED based on the work done on PI-983.
Description
•