1170846 - Warn users when unsigned add-ons have been disabled during startup

Status: RESOLVED DUPLICATE of bug 1170851

(Firefox for Android Graveyard :: Add-on Manager, defect)

Description

[:Margaret Leibovic]

Android version of bug 1151507.

Comment 1

[:Margaret Leibovic]

Katie, are you the right person to ask about add-on FHR data? I'm trying to figure out how common it is for users to have Android add-ons that didn't come from AMO.

According to rnewman, we do record installed add-on IDs in FHR environments, so if I get a count of every add-on, I should be able to see how many aren't on AMO.

Maybe this is also something that we've done for desktop.

Comment 2

[:Margaret Leibovic]

Anthony, on desktop, it looks like we show a notification bar when we detect that unsigned add-ons have been disabled, but we don't have that type of UI on mobile. Should we show a prompt in this case? We could offer to take the user to the add-on manager to learn more about their disable add-ons.

Hopefully we can get some data to learn how often this would occur, but I'm hoping we don't have that many users using non-AMO add-ons.

Comment 3

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: prev_aboutaddons.png

I was hoping to use this more general warning for us on Mobile. But, it seems like this bug is about start up situations... 

I think we could trying showing a prompt in the mean time, but that doesn't seem like the ideal UX. 

Could we perhaps open a tab with "about:addons" open on startup? This is an idea I'm playing with for other parts of the UI but I'm not sure about the implementation restrictions..

Comment 4

[:Margaret Leibovic]

(In reply to Anthony Lam (:antlam) from comment #3)
> Created attachment 8617662 [details]
> prev_aboutaddons.png
> 
> I was hoping to use this more general warning for us on Mobile. But, it
> seems like this bug is about start up situations... 
> 
> I think we could trying showing a prompt in the mean time, but that doesn't
> seem like the ideal UX. 
> 
> Could we perhaps open a tab with "about:addons" open on startup? This is an
> idea I'm playing with for other parts of the UI but I'm not sure about the
> implementation restrictions..

So the UX we need for this bug is actually pretty similar to bug 1170851 (the difference is that with that bug, we're warning at any time while the app is running, whereas for this bug we're warning at startup).

We could open the add-on manager at either of these times, but my main concern is that showing the add-on manager with a warning symbol next to a disabled add-on doesn't really tell the user what's going on.

Maybe we should add a banner at the top of the about:addons UI (above the "Your Add-ons" header), to explain that an add-on was recently disabled.

I'm really hoping that this wouldn't happen often, but I think for the short term (for both this bug and bug 1170851), we should just show a prompt that says that an add-on has been disabled, and provide a link to the add-on manager.

On desktop, the string for this notification is "One or more installed add-ons cannot be verified and have been disabled.", and there's a "Learn more" link that takes the user to about:addons (once I fix bug 1170841, we'll have UI in about:addons to show the unsigned add-ons).

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #4)
> So the UX we need for this bug is actually pretty similar to bug 1170851
> (the difference is that with that bug, we're warning at any time while the
> app is running, whereas for this bug we're warning at startup).
> 
> We could open the add-on manager at either of these times, but my main
> concern is that showing the add-on manager with a warning symbol next to a
> disabled add-on doesn't really tell the user what's going on.
> 
> Maybe we should add a banner at the top of the about:addons UI (above the
> "Your Add-ons" header), to explain that an add-on was recently disabled.
> 
> I'm really hoping that this wouldn't happen often, but I think for the short
> term (for both this bug and bug 1170851), we should just show a prompt that
> says that an add-on has been disabled, and provide a link to the add-on
> manager.

Hm, I feel like we can do better. But I agree, for the mean time, we should put a prompt in and keep it simple.
 
> On desktop, the string for this notification is "One or more installed
> add-ons cannot be verified and have been disabled.", and there's a "Learn
> more" link that takes the user to about:addons (once I fix bug 1170841,
> we'll have UI in about:addons to show the unsigned add-ons).

Great! I wonder if it should be "Learn more" though? We typically hand off to "webpages" like SUMO with these types of "learn more" buttons. 

So perhaps we should offer a "Dismiss" and "View add-ons" as options?

Comment 6

[Katie Parlante]

Unfortunately, I'm not going to be much help before we migrate the FHR v3 data to the new pipeline. My understanding is that the addon data is similar from v2 to v3. Here's some docs: https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/services/healthreport/healthreport/dataformat.html

The folks over in #metrics may be able to help, in particular dzeber has some experience with the addon data.

Comment 7

[:Margaret Leibovic]

(In reply to Katie Parlante from comment #6)
> Unfortunately, I'm not going to be much help before we migrate the FHR v3
> data to the new pipeline. My understanding is that the addon data is similar
> from v2 to v3. Here's some docs:
> https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/services/
> healthreport/healthreport/dataformat.html
> 
> The folks over in #metrics may be able to help, in particular dzeber has
> some experience with the addon data.

Thanks for the tip. I can ask in there to see if we have more add-on data.

For now, I just landed the dialog that we discussed. The patch in bug 1170851 will handle this start-up case as well.