Addons do not show when they are blocklisted

VERIFIED FIXED in mozilla2.0b5

Status

()

defect
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: Unfocused, Assigned: mossop)

Tracking

Trunk
mozilla2.0b5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

(Whiteboard: [rewrite])

Attachments

(1 attachment)

Addons do not show when they are blocklisted. they should have a warning, and potentially be styled differently.

Need to figure out how they should look different.
Keywords: uiwanted
Version: unspecified → Trunk
Assignee

Updated

9 years ago
blocking2.0: --- → beta1+
Currently, when an add-on is added to the blocklist, the user sees a message upon startup that says "These add-ons have a high risk of causing [horrible problems] and have been blocked, but a restart is required to disable them completely."  This screen gives the user the option to restart then, which disabled the add-on, or cancel the message, which keeps them enabled until the next restart.

So, there's two states two deal with: when the add-ons are on the blocklist but still enabled until restart, and the add-ons that are on the blocklist and have been disabled after restart.  The attachment shows two states similar to regular disabled add-ons but with an additional message alerting the user that the add-on is blocked.

The message alerting the user of blocked add-ons we should probably just keep as it is for now.
(In reply to comment #1)
> So, there's two states two deal with: when the add-ons are on the blocklist but
> still enabled until restart, and the add-ons that are on the blocklist and have
> been disabled after restart.

There's also a soft-block, where an addon will be disabled by default, but the user can choose to keep it enabled. In this case, its more of a strong recommendation.


> an additional message alerting the user that the add-on is blocked.

Unfortunately, we don't get data on the reason why an addon was blocked. Its been discussed in the past, but nothing came out of it.
Assignee

Updated

9 years ago
blocking2.0: beta1+ → final+
(In reply to comment #2)
> (In reply to comment #1)
> > an additional message alerting the user that the add-on is blocked.
> 
> Unfortunately, we don't get data on the reason why an addon was blocked. Its
> been discussed in the past, but nothing came out of it.

There are short strings regarding block reason here: http://www.mozilla.com/en-US/blocklist/ .  Can we not use the same strings in the manager?
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > an additional message alerting the user that the add-on is blocked.
> > 
> > Unfortunately, we don't get data on the reason why an addon was blocked. Its
> > been discussed in the past, but nothing came out of it.
> 
> There are short strings regarding block reason here:
> http://www.mozilla.com/en-US/blocklist/ .  Can we not use the same strings in
> the manager?

We have no mechanism for doing that right now, nor do I think are those strings localized.
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > an additional message alerting the user that the add-on is blocked.
> > > 
> > > Unfortunately, we don't get data on the reason why an addon was blocked. Its
> > > been discussed in the past, but nothing came out of it.
> > 
> > There are short strings regarding block reason here:
> > http://www.mozilla.com/en-US/blocklist/ .  Can we not use the same strings in
> > the manager?
> 
> We have no mechanism for doing that right now, nor do I think are those strings
> localized.

Is there anything at all we can know and display about why an add-on is blocked  -  if not a string, perhaps a link to more information?
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > (In reply to comment #1)
> > > > > an additional message alerting the user that the add-on is blocked.
> > > > 
> > > > Unfortunately, we don't get data on the reason why an addon was blocked. Its
> > > > been discussed in the past, but nothing came out of it.
> > > 
> > > There are short strings regarding block reason here:
> > > http://www.mozilla.com/en-US/blocklist/ .  Can we not use the same strings in
> > > the manager?
> > 
> > We have no mechanism for doing that right now, nor do I think are those strings
> > localized.
> 
> Is there anything at all we can know and display about why an add-on is blocked
>  -  if not a string, perhaps a link to more information?

We have in the past just displayed a More Information link to that page.
(In reply to comment #7)
> It actually stated "Disabled for your protection." followed by a "More
> Information" link.
> 
> http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd#115

Alright, for now we can do something similar - "This add-on has been disabled for your protection.  <a=foo>More information</a>"
Assignee

Updated

9 years ago
Assignee: nobody → bparr
Assignee

Updated

9 years ago
Keywords: uiwanted
Needed by string freeze
blocking2.0: final+ → beta5+
Assignee

Updated

9 years ago
Assignee: bparr → dtownsend
Assignee

Updated

9 years ago
Depends on: 585950, 562902
Fixed by bug 585950
Flags: in-testsuite+
Target Milestone: --- → mozilla2.0b5
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre and the blocklisted MetaStream 3 plugin.

Dave, do we need any manual or Mozmill test here?
Status: RESOLVED → VERIFIED
Flags: in-litmus?
I don't see a big need for one.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.