634398 - Implement support for registering XPCOM components and loading NPAPI plug-ins from folders in the profile

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

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

To go along with bug 632269, many (most?) of the useful-to-Camino, mostly-or-fully-UI-less add-ons need to register JS XPCOM components. (Example: https://addons.mozilla.org/en-US/firefox/addon/universal-behavioral-advertisi/, the DNT header add-on for anything Gecko that's not Firefox 4.)

Right now, like bug 632269, it's not possible to install such an add-on unless you hack the bundle to install the component there.

To register from the profile, it looks like we need to implement NS_XPCOM_COMPONENT_DIR_LIST (see http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/xre/nsXREDirProvider.cpp#660 for the XREDirProvider impl).

Similarly, a fairly common request is for a Camino- or Gecko-specific plug-ins directory (usually, people want a PDF plug-in for Camino but don't want it overriding WebKit's built-in PDF support all over the rest of their OS, e.g. bug 325464).  Again, you can do this now by hacking the bundle and putting it with the JEP, but then you have to keep hacking the bundle every update, which sucks.

I believe implementing NS_APP_PLUGINS_DIR_LIST will again let us add a profile-based folder to the existing places Gecko looks for NPAPI plug-ins (again, http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/xre/nsXREDirProvider.cpp#758 for the XREDirProvider impl).

These two are probably a bit "trickier" than the chrome case, because we want to make sure that the components case doesn't happen to mess up our built-in component registration (AppComponents/nsStaticComponents) and that the plug-ins case doesn't forget/skip (~)/Library/Internet Plug-Ins (I have no idea what defines them; MXR returns no hits!)

Comment 1

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

(In reply to comment #0)
> case doesn't forget/skip (~)/Library/Internet Plug-Ins (I have no idea what
> defines them; MXR returns no hits!)

Apparently http://mxr.mozilla.org/mozilla1.9.2/source/xpcom/io/nsDirectoryService.cpp#964

Comment 2

[Stuart Morgan]

Attachment: fix

Comment 3

[Stuart Morgan]

Comment on attachment 512710 [details] [diff] [review]
fix

This assumes the fix for the DTD localization.

The "Internet Plug-Ins" and "components" folders will be created in the profile, and their contents will be used.

Comment 4

[Stuart Morgan]

Landed http://hg.mozilla.org/camino/rev/8e477c92e03c

Leaving sr? for post-landing review.

Comment 5

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

One thing that I just figured out (but which I've been pulling my hair out for several hours trying to figure out what I had done in my chrome changes, when in fact I'd done nothing ;) ) is that the profile plug-ins folder doesn't get created at startup; it gets created the first time something asks for plug-ins.  (Something asks for components at the get-go.)  This is probably not an issue in reality, but it can be confusing on first-run profiles.

Also, either this or bug 457290 caused about a 15ms Ts regression on both Xserves (it's impossible to tell which due to the landing windows), though I guess that's to be expected with additional chrome registration and folder enumeration/creation.