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

RESOLVED DUPLICATE of bug 1170851

Status

()

Firefox for Android
Add-on Manager
RESOLVED DUPLICATE of bug 1170851
3 years ago
3 years ago

People

(Reporter: Margaret, Assigned: Margaret)

Tracking

35 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
Android version of bug 1151507.
(Assignee)

Comment 1

3 years ago
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.
Flags: needinfo?(kparlante)
(Assignee)

Comment 2

3 years ago
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.
Flags: needinfo?(alam)
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..
Flags: needinfo?(alam) → needinfo?(margaret.leibovic)
(Assignee)

Comment 4

3 years ago
(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).
Flags: needinfo?(margaret.leibovic) → needinfo?(alam)
(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?
Flags: needinfo?(alam) → needinfo?(margaret.leibovic)

Comment 6

3 years ago
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.
Flags: needinfo?(kparlante)
(Assignee)

Comment 7

3 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(margaret.leibovic)
Resolution: --- → DUPLICATE
Duplicate of bug: 1170851
You need to log in before you can comment on or make changes to this bug.