391714 - Notify user when plugin is blocklisted

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P4)

Description

[Michael Wu [:mwu]]

The user should be notified when a plugin is blocklisted.

Comment 1

[Robert Strong (they/them - no direct email)]

and provide an option to update the plugin if an update is available via PFS

Comment 2

[Mike Connor [:mconnor]]

will we be able to tell when laying out a page that its a blocked plugin, rather than an unavailable plugin?  If so, we can simply present a very similar UI to the PFS experience, and let a user install a new plugin.  I don't think an additional notification is really necessary, i.e. if I have a blocked plugin, but I never hit a page where I need the plugin, notification is unnecessary.

Comment 3

[Robert Strong (they/them - no direct email)]

The request for the additional notification was from you and schrep so we could proactively notify users that have plugins in the blocklist after first run after an upgrade.

Comment 4

[Mike Connor [:mconnor]]

hmm, ok.  I keep coming backto nsIAlertService to fill that notification.  Have we thought about hooks in the EM to show available updates from PFS?

Comment 5

[Robert Strong (they/them - no direct email)]

(In reply to comment #4)
> hmm, ok.  I keep coming backto nsIAlertService to fill that notification.
Has the work been done to extend nsIAlertService?

> Have
> we thought about hooks in the EM to show available updates from PFS?
I've thought about it recently... plugins core and plugins themselves don't have a concept of an ID for a plugin which made us use multiple values to identify a plugin for blocklisting and we also need PFS to understand updates to existing installed plugins vs. just installation of missing plugins.

Comment 6

[Dave Townsend [:mossop]]

Do we want this for Firefox 3, and if so what exactly are we wanting. 

Notification that a page is trying to use a blocklisted plugin (needs bug 393316 I think)?

Notification that one of the users plugins has just been blocked?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #6)
> Do we want this for Firefox 3, and if so what exactly are we wanting. 
> 
> Notification that a page is trying to use a blocklisted plugin (needs bug
> 393316 I think)?

Most definitely, and I'm blocking on this bug for this.

> Notification that one of the users plugins has just been blocked?

I've filed bug 398365 for this.

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #8)
> (In reply to comment #6)
> > Do we want this for Firefox 3, and if so what exactly are we wanting. 
> > 
> > Notification that a page is trying to use a blocklisted plugin (needs bug
> > 393316 I think)?
> 
> Most definitely, and I'm blocking on this bug for this.

Didn't spot it before but I think that means this is just a dupe of bug 388445

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Hm, yes it would, but actually, I think I'd misread/misinterpreted. Let's clarify the intent:

As per comment 3 in this bug, this bug is about pro-actively notifying a user (f.e., on startup) that 1 or more of their plugins have just been blocklisted and are thus disabled, so reed was right, bug 398365 dupes to this one.

Bug 388445 is about notifying a user that they can't see content on a page because a plugin is disabled due to blocklisting.

(So say we all!)

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #4)
> hmm, ok.  I keep coming backto nsIAlertService to fill that notification.

I could buy that.

> Have we thought about hooks in the EM to show available updates from PFS?

That's a good question. It would be nice to get updates, but I believe most plugins don't let us update via XPI. Still, some way to say "updates are available" and even open tabs to the pages where users can get and install those updates would be a nice experience.

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #10)
> As per comment 3 in this bug, this bug is about pro-actively notifying a user
> (f.e., on startup) that 1 or more of their plugins have just been blocklisted
> and are thus disabled, so reed was right, bug 398365 dupes to this one.

In which case if this is the same as bug 398365 was then I don't believe it should be blocking as you marked that bug as just wanted.

Comment 14

[Dave Townsend [:mossop]]

Need some kind of idea of the UI we want here. The alerts service has been suggested. We could use a generic string in it and then when clicking bring up the add-ons manager with the plugins pane selected perhaps.

Comment 15

[Dave Townsend [:mossop]]

Might be able to find time to get to this if a response to comment 14 is forthcoming, but dropping from my list for now.

Comment 16

[chris hofmann]

there are some UI ideas kicking around in bug 422994 for clean up to extension blocking UI.  would it make sense to just leverage that?

Comment 17

[Daniel Veditz [:dveditz]]

If we're going to get this kind of UI niceness it's going to have to wait for 3.1 -- can we put it on the todo list? If we don't it's not going to happen.

Comment 18

[Dave Townsend [:mossop]]

For this to work I believe we will need a few API changes. Currently the blocklist service tells the EM than a new blocklist is available and the EM then displays what was blocked. We probably need to change this so the EM simply returns a list of newly blocked items which the blocklist service can combine with a list of newly blocked plugins for display in a single dialog.

Comment 19

[Dave Townsend [:mossop]]

Fixed by bug 455906

Comment 20

[Tony Chung [:tchung]]

Verified fix from bug 455906

Comment 21

[Tony Chung [:tchung]]

fixed on 1.9.1 too