Closed Bug 316593 Opened 19 years ago Closed 2 years ago

Support for Plug-in Finder Service (PFS)

Categories

(Camino Graveyard :: Plug-ins, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Future

People

(Reporter: vlad.alexander, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

Camino should support Plug-in Finder Service (PFS). This feature is available in Firefox and is an important plug-in distribution method for us.

Reproducible: Always

Steps to Reproduce:
1. Open a Web page containing <object> element for a plug-in that is not installed.


Actual Results:  
User does get the option to install missing plug-in.

Expected Results:  
A yellow bar should display at the top of the browser window with a button to install missing plug-ins.
Confirming per IRC discussion and targeting for 1.2.

cl
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.2
CC some random people;  Does anyone know what we'd need to get the same kind of plug-in finder service as Firefox?

Thanks!
Assignee: mikepinkerton → nobody
QA Contact: plugins
A UA stylesheet with an XBL binding. This is how firefox does this:
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/plugins/pluginGlue.js registers the stylesheet
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/plugins/content/missingPluginBinding.css is the stylesheet it registers
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/plugins/content/missingPlugin.xml is the XBL binding it uses

The infobar is triggered by the PluginNotFound event; I can't recall how exactly the actual wizard is triggered, possibly only via the infobar.

You'll also want to set "plugin.default_plugin_disabled" to true.
Oh, that was all for trunk, branch is different...
So for branch, you don't need the CSS/XBL. You do need to handle the PluginNotFound event and need to set the same pref. You need to provide a "chrome://mozapps/skin/xpinstall/xpinstallItemGeneric.png" image and a "chrome://mozapps/locale/plugins/plugins.properties" file for the image/text to show up correctly. that should be sufficient as far as I can tell.
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Since the Default Plug-in no longer offers plug-in finding services on 1.9.2, we maybe want to think about this for 2.1.

We'd need to package dist/bin/components/pluginGlue.js and set "plugin.default_plugin_disabled" to true; that gets us the in-content UI.  It's completely non-functional, but that's the same as the Default Plug-in on 1.9.2.

Beyond that come the problems (read: NOT EMBEDDING FRIENDLY!!!).

We'd need to listen for the PluginNotFound event (assuming that hasn't changed since comment 3) to show a transient bar on pageload (assuming we want a transient bar an not just the in-content UI).

Clicking on the transient bar or on the in-content UI (I guess generates an event which) launches a XUL wizard (http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/mozapps/plugins/content/pluginInstallerWizard.xul?force=1) which I guess runs http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/mozapps/plugins/content/pluginInstallerService.js?force=1.

So we'd need to reimplement the wizard UI+wizard brains, and anything else it talks to, in Cocoa, start building and shipping xpinstall (bleh) and hope it works, and, generally, pray.

---

As an alternative to all of that reimplementing work, I suppose we could listen for the event or whatever that triggers the XUL wizard and instead construct a PFS query and parse it[1] and just offer the download URL (or even start the download), which would be about on par with what the Default Plug-in offered, and a lot less work than making the installation process embedding-friendly.

[1] https://wiki.mozilla.org/PFS (and PFS gen2, https://wiki.mozilla.org/PFS2 )
(In reply to comment #7)
> Beyond that come the problems (read: NOT EMBEDDING FRIENDLY!!!).

That sucks. Can we ask for them to make it friendly for us? I believe we have a standing offer from Josh to help us move up and given that he works on plug-in code and widget code...

Listening for whatever event doesn't seem very future proof and I kind of bet it'll break with each major version. Who worked on the PFS stuff in toolkit that we can lean on?
(In reply to comment #8)
> That sucks. Can we ask for them to make it friendly for us?

You mean make the missing plug-in/PFS API suitable for use with something other than a XUL Wizard?  Possibly it already is; someone other than me needs to look at the code (and the support code scattered all over browser.js in Firefox).

> standing offer from Josh to help us move up and given that he works on plug-in
> code and widget code...

This is neither of those, really; it's toolkit XUL (the part that interfaces with PFS is probably most closely related to EM).

> Listening for whatever event doesn't seem very future proof and I kind of bet
> it'll break with each major version.

Ordinarily I'd disagree with you (I presume the Wizard is listening for the same events from the "missing plug-in" UI and the infobar), but after the experience of bug 548486, I'm more likely to agree.  OTOH, it looks like the binding doesn't register any events at all, so that Firefox registers its own event and responds to it by manually opening the wizard (so registering our own event, if we can do that, on the in-content UI and then responding to that event in whatever way we choose, seems safe): http://mxr.mozilla.org/mozilla1.9.2/source/browser/base/content/browser.js#6050

Oh, no, wait; the XBL binding used to provide the click event for the in-content UI (it was the PluginNotFound event), which is how PFS managed to work in SeaMonkey; however, bug 539848 moved the clickhandler out of the XBL and into Firefox's browser.js--in effect doing just what Sam feared, pulling the event out from under everyone else and requiring them to roll their own solution for installing a click event handler, listening for said click event, and handling clicks on the in-content UI :P  Mozilla ftw!

> Who worked on the PFS stuff in toolkit that we can lean on?

doron(!), bsmedberg, mossop are in the blame for the .js file.

---

As a general update here, for Cm2.1-M1.9.2, bug 561919 has now 1) shipped pluginGlue.js and 2) flipped the pref, so we get the content-based missing plug-in UI.  That leaves the 
> Beyond that come the problems (read: NOT EMBEDDING FRIENDLY!!!).
stuff.
We're not going to do PFS for 2.1 (see most of comment 7, comment 8, and comment 9 if you don't understand why).

We are directing missing plug-in cases to http://caminobrowser.org/documentation/setup/#find_plugin (since we're now using pluginGlue.js and have forked its XBL).

We may also do bug 626512, but that's the closest we're going to come.
Flags: camino2.1? → camino2.1-
Target Milestone: --- → Future

This bug lies at rest in the graveyard.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.