Closed Bug 1907368 Opened 4 months ago Closed 3 months ago

Replace AMO collection screen with Addons Picker in about:welcome defaults

Categories

(Firefox :: Messaging System, task, P1)

task
Points:
1

Tracking

()

VERIFIED FIXED
131 Branch
Iteration:
131.1 - Aug 5 - Aug 16
Tracking Status
firefox131 --- verified

People

(Reporter: emcminn, Assigned: emcminn)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Based on the improvement to addon installations in onboarding seen in this experiment, we should replace the AMO collection screen in the about:welcome defaults with the addons picker. We can use the addons from the more successful branch (Privacy.)

See also: https://docs.google.com/document/d/1U9a02UU8wXITklEg7oDE6dT1aTyImY38mqtpbGy_65w/edit#heading=h.5840t7jz7l1f

Status: NEW → ASSIGNED
Iteration: --- → 130.1 - Jul 8 - Jul 19
Points: --- → 1
Priority: -- → P1

This will need to include translation of these strings. Also note that bug 1908210 will make the install label configurable and our goal is to uplift this into 129 release.

(In reply to Meg Viar [:mviar] from comment #2)

This will need to include translation of these strings. Also note that bug 1908210 will make the install label configurable and our goal is to uplift this into 129 release.

So while I agree we should land the addons picker strings in the translated file, I don't think it needs to necessarily block this. The original intention was to land it with the same screen targeting as the AMO collection (i.e. targeting: "localeLanguageCode == 'en'") so that it would be available to EN locales immediately, and then follow up with translations and remove the en-* only targeting once experimentation had been done.

(In reply to Emily McMinn :emcminn from comment #3)

(In reply to Meg Viar [:mviar] from comment #2)

This will need to include translation of these strings. Also note that bug 1908210 will make the install label configurable and our goal is to uplift this into 129 release.

So while I agree we should land the addons picker strings in the translated file, I don't think it needs to necessarily block this. The original intention was to land it with the same screen targeting as the AMO collection (i.e. targeting: "localeLanguageCode == 'en'") so that it would be available to EN locales immediately, and then follow up with translations and remove the en-* only targeting once experimentation had been done.

Thanks, Emily. That makes sense to me if we're just targeting EN locales to start. FYI we've pushed back the localized experiment until after bug 1908210 lands so that we can localize the install buttons (so likely Fx129 or Fx130 release).

Blocks: 1908708
No longer blocks: 1908708
Iteration: 130.1 - Jul 8 - Jul 19 → 130.2 - Jul 22 - Aug 2
Iteration: 130.2 - Jul 22 - Aug 2 → 131.1 - Aug 5 - Aug 16
Attachment #9412808 - Attachment description: WIP: Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome → Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome

I've updated the addons in the picker to reflect Scott's feedback on OMC-752; this should be ready!

Attachment #9412808 - Attachment description: Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome → WIP: Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome
Attachment #9412808 - Attachment description: WIP: Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome → Bug 1907368 - Replace AMO collection screen with addons picker in about:welcome
Pushed by emcminn@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bf43aa62c099 Replace AMO collection screen with addons picker in about:welcome r=omc-reviewers,mviar
Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c59d951eb773 Fix failures about browser_all_files_referenced. a=test-only
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch

(In reply to Pulsebot from comment #7)

Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c59d951eb773
Fix failures about browser_all_files_referenced. a=test-only

This added an exception for this file but all references for the file are gone. Shouldn't the file be removed instead?

Flags: needinfo?(emcminn)

The file is still referenced in some messages that are live on RS, similar to the mr-privacysegmentation.svg. We're also actively experimenting with messaging around addons/addons collections so there's a good chance we'll have new use cases for that illustration in the near future.

We could always take a look at moving those files that have exceptions over to RS and using them from there - that would shrink the installer size by a tiny bit (the images are optimized to be pretty small), but would potentially have an impact on perceived load times as the images are fetched from RS.

Flags: needinfo?(emcminn)

(In reply to Emily McMinn :emcminn from comment #10)

The file is still referenced in some messages that are live on RS, similar to the mr-privacysegmentation.svg. We're also actively experimenting with messaging around addons/addons collections so there's a good chance we'll have new use cases for that illustration in the near future.

Ah, thanks for clarifying! Do we have a bug on file to add automated testing (assuming it doesn't exist already) that would flag any resources like this once we do stop using the resources from such live RS messages?

We could always take a look at moving those files that have exceptions over to RS and using them from there - that would shrink the installer size by a tiny bit (the images are optimized to be pretty small), but would potentially have an impact on perceived load times as the images are fetched from RS.

Based on the pros/cons you describe that doesn't sound worth pursuing at the moment, especially for about:welcome as it's used straight after startup.

Flags: needinfo?(emcminn)

(In reply to :Gijs (he/him) from comment #11)

Ah, thanks for clarifying! Do we have a bug on file to add automated testing (assuming it doesn't exist already) that would flag any resources like this once we do stop using the resources from such live RS messages?

We don't AFAIK! That would be handy. I'm curious if there's a way we could leverage the Skylight tool for this, since it's intended to give us a clearer overview of what messages are live/ "in-flight" at any given time. I'll bring it to the team and maybe we can come up with something :)

Flags: needinfo?(emcminn)

I have verified this task and can confirm that the "Addons Picker" screen is displayed instead of the "AMO collection" one on the "about:welcome" page.

Verified using the latest Firefox Nightly 131.0a1 (Build ID: 20240821160637) installed on Windows 10 x64, macOS 14.5, and Ubuntu 22.04 x64.

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

Attachment

General

Created:
Updated:
Size: