626512 - Hook up UI for outdated plugin notification

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Plug-ins, defect)

Description

[Stuart Morgan]

The plugin blocklist service lets us mark plugins as outdated; I believe based on the code that this fires an event whenever an outdated plugin is loaded.

We should look into setting up a listener for that event, and using it to show an info bar with a link to something to help them update.

Smokey said there's something embedding-unfriendly about this system, but I've forgotten what it is already, so hopefully he'll chime in with details and links :)

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)
> The plugin blocklist service lets us mark plugins as outdated; I believe based
> on the code that this fires an event whenever an outdated plugin is loaded.
[...]
> Smokey said there's something embedding-unfriendly about this system, but I've
> forgotten what it is already, so hopefully he'll chime in with details and
> links :)

PFS and the blocklisting service are related in that they both depend on the pluginGlue.js pseudo-module and its active element XBL, pluginProblem.xml (which we just forked).

PFS is entirely embedding-unfriendly because it's 100% XUL (checking for plug-ins for unknown content-types and then installing them); that's not relevant here, only for bug 316593.

What's unfriendly here is that, prior to bug 539848, the XBL provided the events for missing, disabled, and blocked plugins (that triggered the infobar in Firefox) and the click-handling for the placeholders (which sent another event that triggered PFS or the Extension Manager, depending on the event/case) in Firefox.

Bug 539848 moved the event-firing and click-handling entirely out of the shared component and into browser.js.

So, at least in the missing case, we'd have to install our own click-handlers and event listeners and figure out if we're clicking/loading the placeholder, and then fire the relevant events and handle the relevant clicks ourselves, i.e. implement the entire lifecycle.  See the two meaty paragraphs in bug 316593 comment 9.

If the Gecko blocklist service really fires its own event, that's better than the missing plug-in situation---but if blocklisting was relying on the plug-in placeholder XBL for event firing back when blocklisting was implemented, it's now relying on browser.js to do it and not sending an event at all.  You're in a better position than me to judge ;)

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Did we want this for 2.1?

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)
> The plugin blocklist service lets us mark plugins as outdated; I believe based
> on the code that this fires an event whenever an outdated plugin is loaded.

This is probably nsObjectLoadingContent.cpp's |nsPluginErrorEvent::Run|, so it should work: http://mxr.mozilla.org/mozilla1.9.2/source/content/base/src/nsObjectLoadingContent.cpp#193

It's possible (likely) that I misunderstood the Firefox code; the infobar and the in-content UI both listened for the same events, but the Firefox code only moved setting the click-handler's sending of those events out of the Gecko plug-in UI component and into Firefox (because the browser was already getting the events from nsObjectLoadingContent.cpp for the infobar, and there was nothing in the browser.js to indicate that).

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Plug-in event logging

Yep, we get the events*.  This patch just registers for them and NSLog()s when we get them.  Someone might be able to talk me through writing the rest of the code, but most likely it won't be me fixing this ;)

* We do not seem to get a "PluginOutdated" event currently, from, e.g., Flash 9 with the patch for bug 626477 applied; we do get the other three.  Presumably there's something else we need to hook up to "mark plugins as outdated" per comment 0.

Comment 5

[Stuart Morgan]

Yeah, we'd have to change our blocklist code to mark things as outdated.

I don't think we should try to add this to 2.1. We're already so far behind where we want to be, and this adds new UI, which will need nibs, debugging, etc. I think we should focus on our closing out b1 as soon as humanly possible.

If we feel super-productive we could always do a really really limited 2.2 (really, not like our usual "limited scope" releases ;) ) with things like this.

Comment 6

[Takanori MATSUURA]

This bug lies at rest in the graveyard.