Closed Bug 1181835 Opened 9 years ago Closed 6 years ago
Provide a UI for migrating users' add-ons to webextensions
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).
Nick & Kev, we need to figure out what we want to do here
Based on the release criteria discussion, thisd no longer blocks e10s rollout.
No longer blocks: e10s-miscblockers
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?"
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?"
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).
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
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.
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.
Depends on: 1136927
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.
redirecting to Barbara
Flags: needinfo?(nnguyen) → needinfo?(bbermes)
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?
Flags: needinfo?(bbermes) → needinfo?(blassey.bugs)
(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
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. :)
Design work on this bug currently happening on GitHub: https://github.com/mozilla/addons/issues/48
moving under deployment bug - adding Need Info for me to work on requirements
So is this now about offering alternatives to users, like specified on this PRD , or the migration flow once a user updates to 57? Both?  https://docs.google.com/document/d/19CB11uJbhz2txgP9AMPdvAcqjTHubQvEHU5E17LiaTs/edit
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"
We've got the "find replacement" UI in about:addons as mentioned in comment 17. Is there anything else to be done here?
(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.
You need to log in before you can comment on or make changes to this bug.