Open Bug 1027535 Opened 6 years ago Updated 4 years ago

Addon Manager doesn't provide enough details in case of blocklisted addons

Categories

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

All
Android
defect

Tracking

()

Tracking Status
fennec + ---

People

(Reporter: pauly, Unassigned)

References

Details

Attachments

(1 file)

On Firefox for Android, in case of blocklisted addons (due to vulnerability issues, malware etc), Addon Manager just shows them as "disabled" (grayed out).
Android should copy the FF desktop behavior and display something like:
"The addon is known to cause security or stability issues".

FF android vs desktop: https://bug999784.bugzilla.mozilla.org/attachment.cgi?id=8442073
tracking-fennec: --- → ?
Ian what do you want to do?
Flags: needinfo?(ibarlow)
Sure, we could add some UI to tell users what's going on. couple questions and thoughts:

How often does this happen? To what extent are Android add-ons blocklisted? Is it so much that we need to fix this right this moment?

The reason I ask is that we've also been batting around the idea of refreshing our add-ons management experience for some time now, either by putting all of it in settings (as in bug 891115), or even just giving our existing in content UI more of a refresh. I'd be inclined to roll this bug's ask into a larger refresh like this if possible.
Flags: needinfo?(ibarlow)
Probably in the same situation are the outdated/vulnerable plugins blocked by the 'Click to Play' feature.
(In reply to Ian Barlow (:ibarlow) from comment #2)
> Sure, we could add some UI to tell users what's going on. couple questions
> and thoughts:
> 
> How often does this happen? To what extent are Android add-ons blocklisted?
> Is it so much that we need to fix this right this moment?
I don't think it's a huge problem and doesn't fall into the "hurry up and fix this now" bucket.

> The reason I ask is that we've also been batting around the idea of
> refreshing our add-ons management experience for some time now, either by
> putting all of it in settings (as in bug 891115), or even just giving our
> existing in content UI more of a refresh. I'd be inclined to roll this bug's
> ask into a larger refresh like this if possible.
what's the timeline for that?
Flags: needinfo?(ibarlow)
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #4)

> > The reason I ask is that we've also been batting around the idea of
> > refreshing our add-ons management experience for some time now, either by
> > putting all of it in settings (as in bug 891115), or even just giving our
> > existing in content UI more of a refresh. I'd be inclined to roll this bug's
> > ask into a larger refresh like this if possible.

> what's the timeline for that?

We need to assign it to a release and stick to it. We've been bumping it each release for about a year now.
Flags: needinfo?(ibarlow)
sounds like it's on to product for priorization then
Flags: needinfo?(krudnitski)
tracking-fennec: ? → +
How is this actually managed? Who is responsible for saying an add-on is known to cause security or malicious issues? How is it then re-reviewed if the add-on is deemed fix? My worry here is that we'd be making a public label and we would need to be absolutely certain this was the case.

If this is a manual process (verifing and re-verifying), what's the extra benefit in informing users the cause if this is a 'hardly ever' occurrence? Is there an alternate area on SUMO or the AMO that could state why an add-on has been disabled instead of in-product?
Flags: needinfo?(krudnitski)
filter on [mass-p5]
Priority: -- → P5
Blocks: 1053397
No longer blocks: 891115
Hi, Paul

The screenshot is a prototype copied the style and behavior from current desktop add-on manager. 

It has been a long time since last updated, could you give me some feedback whether this meets requirement? Thanks.
Flags: needinfo?(paul.silaghi)
Hi Ray,
Looks fine to me, but you should better ask UI/UX for a more accurate review on this.
Also note that a similar behavior is probably also needed for other types of addons/plugins (eg: http://i.imgur.com/qoezbEz.png)
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(alam)
(In reply to Ray Lin[:ralin] from comment #9)
> Created attachment 8764534 [details]
> Screenshot_2016-06-23-08-01-35.png
> 
> Hi, Paul
> 
> The screenshot is a prototype copied the style and behavior from current
> desktop add-on manager. 
> 
> It has been a long time since last updated, could you give me some feedback
> whether this meets requirement? Thanks.

Nice work Ray! 

But before we move forward here, I think we should take a step back and consider the (somewhat related) other efforts on about:addons. E.g. Bug 1170113 (supporting signed add-ons) and bug 1079504 (UI for about:addons)

I'm a bit unclear what the goal is here so I need some more time to think about this one. So let's hold off for now. 

I'm going to CC' Pwalm here who's been thinking about this more than I have so as to get this on his radar too.
Flags: needinfo?(alam)
Flags: needinfo?(margaret.leibovic)
You need to log in before you can comment on or make changes to this bug.