Closed Bug 391714 Opened 13 years ago Closed 11 years ago

Notify user when plugin is blocklisted

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b2

People

(Reporter: mwu, Assigned: mossop)

References

Details

(Keywords: verified1.9.1)

The user should be notified when a plugin is blocklisted.
and provide an option to update the plugin if an update is available via PFS
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.
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.
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?
(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.
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?
Flags: blocking-firefox3?
Duplicate of this bug: 398365
(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.
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M10
Depends on: 393316
Assignee: nobody → dtownsend
(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

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!)
Duplicate of this bug: 398365
(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.
(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.
Flags: blocking-firefox3+ → blocking-firefox3?
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
Priority: P2 → P4
Target Milestone: Firefox 3 M10 → Firefox 3 M11
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.
Keywords: uiwanted
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.
Assignee: dtownsend → nobody
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?
Depends on: 422994
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.
Flags: blocking-firefox3.1?
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.
Product: Firefox → Toolkit
Target Milestone: mozilla1.9beta3 → ---
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Keywords: uiwanted
Target Milestone: --- → mozilla1.9.1
Status: ASSIGNED → NEW
Depends on: 455906
Fixed by bug 455906
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b2
Flags: in-testsuite+
Flags: blocking1.9.1? → blocking1.9.1+
Verified fix from bug 455906
Status: RESOLVED → VERIFIED
fixed on 1.9.1 too
You need to log in before you can comment on or make changes to this bug.