1181835 - Provide a UI for migrating users' add-ons to webextensions

Status: RESOLVED FIXED

(Firefox :: Extension Compatibility, defect, P2)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We're still not exactly sure how this would work, but I think the basic idea is as follows. On startup, you would be shown a tab with a list of your add-ons. For each add-on, we would show its status:

- e10s compatible (doesn't use CPOWs at all)
- e10s functional (works, uses CPOWs, probably will make Firefox slower)
- broken with e10s

For each add-on not in the first category, we'd like to provide alternatives:
- disable the add-on
- upgrade to a beta version that works better
- upgrade to a slightly different add-on (Firebug 2 -> Firebug 3 for example)

We would probably also show this UI whenever the status of an add-on changes (for example a disabled add-on being made e10s-compatible).

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Nick & Kev, we need to figure out what we want to do here

Comment 2

[Jim Mathies [:jimm]]

Based on the release criteria discussion, thisd no longer blocks e10s rollout.

Comment 3

[Madhava Enros [:madhava]]

Adding Markus and Michael Verdi.

Verdi - I wonder if there's any existing work we have from (or opportunity to have a similar experience to) Firefox Reset? Anything for that step of "what if we can do more than just disable your add-ons wholesale?"

Comment 4

[Kev Needham [:kev]]

I worry about adding any kind of complexity to the experience. Presenting users with multiple options for (potentially) multiple add-ons is something I'd want a little more context on. I like the idea of being able to alert the user and give them a simple choice, but that then leads to "but do we want that?". Might it make more sense to look at adding the detail in the manager, with a simple notification and response for most users that'd disable e10s-incompatible (or known to be not awesome) and provide more detail in AOM, where disabling and enabling is simpler?

(In reply to Madhava Enros [:madhava] from comment #3)
> Adding Markus and Michael Verdi.
> 
> Verdi - I wonder if there's any existing work we have from (or opportunity
> to have a similar experience to) Firefox Reset? Anything for that step of
> "what if we can do more than just disable your add-ons wholesale?"

Comment 5

[Markus Jaritz [:designakt] (UX)]

Can we make this into something of value to the user?
I am thinking along the lines of: "Let us refresh your Firefox! More safe, more speed..." 
With that we could combine all UI around add-ons that will break with signing, with all the stuff that happens with e10s in one refresh that even might appear as having some value to the user.
Ideally we would know if an add-on is used or not and base our recommendation on that. Removing unused add-ons without replacement, and offering to install replacements for used add-ons resulting in a potential one click refresh experience. And maybe even combine this with a more general suggestions on how to customize your Firefox, based on your personal needs (https://invis.io/PW4LMNXE7).

Comment 6

[vkrishnamoorthy]

Product Triage (Verdi, vishy, Erin): We feel that there has to be some "experience" that notifies that some add-ons may not work and the possible path forward. We think that this should be part of the final release but not necessarily for the Beta

Comment 7

[Markus Jaritz [:designakt] (UX)]

There are 2 dimensions to the initial proposal: 
1) telling users that we have to deactivate some add-ons (we decided which)
and 
2) provide possible alternative (beta or other add-on) for users who care.

which are the same options we have been talking about with signing in bug 1148403.

For signing we decided to not present all users with a tab showing all broken add-ons, but rather only notify them that some have been deactivated and provide a way to see more detail for users that are really interested in those. Notification & Details. (https://bug1148403.bmoattachments.org/attachment.cgi?id=8598783)

This provides a default for how we deal with affected add-ons and does not force users to act on something they might not understand, while still allowing more advanced users to dig deeper and get a list of the affected add-ons. (as Kev mentioned in his comment)

This might already be sufficient for a first version and is exactly what we already implemented for deactivated unsigned add-ons.

A second version could introduce suggestions for each affected add-ons, in the way we proposed for unsigned add-ons. (https://bug1148403.bmoattachments.org/attachment.cgi?id=8586071) If we manage to come up with suggestions for the affected add-ons.

Moving forward with this solution I would suggest combining the unsigned warnings and e10s warnings in one view, and not open a second view of deactivated add-ons.

Comment 8

[Erin Lancaster [:elan]]

FYI: Product has decided that Slow Add-On warnings are not required for e10s to be enabled in GA. The proposed plan of record is that we are targeting users without add-ons for Fx45 GA. Bug 1136927 tracks the API work for the Slow Add-Ons warning, specifically. It may not be a hard blocker for the migration story but wanted to add it to this ticket's tree so we don't lose track.

Comment 9

[Tony Mechelynck [:tonymec]]

We should also decide (or maybe we already have?) what to do when a user who hasn't got any add-ons yet — other than system add-ons of course (e.g., someone who just installed Firefox) decides to install one, and in particular, one which is known to be slow, or worse, to break, when e10s is on.

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

redirecting to Barbara

Comment 11

[Barbara Bermes [:barbara] - NI please!]

blassey, as I understand the NI, I probably should follow up once we know when Add-ons will be shipped with e10s? Or is it related to #9?

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Barbara Bermes [:barbara] from comment #11)
> blassey, as I understand the NI, I probably should follow up once we know
> when Add-ons will be shipped with e10s? Or is it related to #9?

Right, this isn't for the first release with e10s. This is for when we ship to users with unsupported add-ons

Comment 13

[Kev Needham [:kev]]

This is a goal for add-ons manager work in Q2 to have everything ready or at least in progress, so I'll follow-up with Barbara as well. There's a bunch of use cases to cover including:

- Existing, installed add-ons that aren't e10s-compatible
- Existing, installed add-ons that are shimmed
- Attempted user install for Add-ons that aren't known to be compatible
- Attempted sideload install for Add-ons that aren't known to be compatible
- Suggestions for alternatives/additional info on options

We should also cover whether we're going to provide advance notice for users about add-ons that will be disabled when we go live. Ties into drawing attention to add-ons the user may not know are installed, as well as mitigating surprises at the time we enable e10s generally.

Barbara, good material for next week. :)

Comment 14

[Markus Jaritz [:designakt] (UX)]

Design work on this bug currently happening on GitHub:
https://github.com/mozilla/addons/issues/48

Comment 15

[:shell escalante]

moving under deployment bug - adding Need Info for me to work on requirements

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

So is this now about offering alternatives to users, like specified on this PRD [1], or the migration flow once a user updates to 57? Both?

[1] https://docs.google.com/document/d/19CB11uJbhz2txgP9AMPdvAcqjTHubQvEHU5E17LiaTs/edit

Comment 17

[Markus Jaritz [:designakt] (UX)]

I think alternatives and migration are closely connected for users that have addons requiring migration. - They might want to know about it prior to 57 or want to find replacements for their addons prior or with 57.

A second bug could be focused on users that do not have legacy addons but want to find addons: "Provide a UI for helping users' choose webextensions over legacy add-ons"

Comment 18

[Andy McKay]

We've got the "find replacement" UI in about:addons as mentioned in comment 17. Is there anything else to be done here?

Comment 19

[emanuela [ux]]

(In reply to Andy McKay [:andym] from comment #18)
> We've got the "find replacement" UI in about:addons as mentioned in comment
> 17. Is there anything else to be done here?

I think we're good.