Question

Possibly this is related to Using a plugin generated with Firebreath in a Firefox Extension?; however, my question is possibly more specific, so here goes…

I’m working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. The resulting plugin on this platform is an “npXXX.so” file, which I got symlinked in ~/.mozilla/plugins. Then, I have coded an extension that uses this plugin – and apart from the symlink, nothing else seems required – all seems to work just smashing 🙂

So, knowing that “firefox supports installing your plugin via XPI. This is not recommended by the FireBreath team“, now I’d still like to package the extension AND the plugin into an XPI file. So, I’m reading a bit on Structure of an installable bundle – MDN, and I can see these two possibilities:

/components/*   XPCOM components (*.js, *.dll), and interface files from *.xpt  (>=1.7)
...
/plugins/*  NPAPI Plugins   (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3

Now, it says: “The older XPCOM- and LiveConnect-based APIs for plugins should not be used.“, so I guess the “/components” directory should not be used (even if it is given as an example in the above page). And I can not find this stated explicitly anywhere, but I’m guessing FireBreath builds NPAPI plugins – so presumably “/plugins” is the way to go. (_{There is also mention of “/platform“, but it clearly says it’s been deprecated for Firefox > 3.6}).

 

Ok, so far so good… So I try to copy the plugin file to plugins/linux inside the extension directory:

cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/

… and then insert the following in chrome.manifest:

binary-component    plugins/linux/npXXX.so ABI=Linux_x86-gcc4

… then I zip the whole extension directory (the plugin included) as an .xpi, try to install it on a different computer. There, the .xpi succesfully installs, the .so file is indeed unpacked under the profile’s extensions/XXX/plugins/linux/ directory – and every cross-platform (javascript) code of the extension works fine; except that the plugin cannot be found.

Now, of course, the user could themselves symlink the extension .so to ~/.mozilla/plugins/; however, I would like to spare the user of that 🙂

 

How would I go about this kind of packaging thing – is there a recommended way to do it?

Many thanks in advance for any answers,
Cheers!

 

Edit: found Shipping a plugin as a Toolkit bundle – MDN which claims only install.rdf , and a plugins/obj.so is needed; then I found Running Quake Live in Firefox 4, 5 and 6 on Linux [fixes inside], referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.. If I install that, I get both a Quake extension and a Quake plugin (and that even with Error Console complaining “Could not read chrome manifest file ‘/path/to/extensions/[e-mail]/chrome.manifest’.“) …. but if I try the same with my FireBreath plugin (e.g. just an install.rdf and plugin in /plugins), only extension gets shown – no plugin (and no reasonable error messages).. Could this be a problem with FireBreath?

Answer 1

Well, I’ll post this as an answer – I have just confirmed that FireBreath plugin does in fact work being packaged in the simple “toolkit bundle” way as an .xpi extension.

Basically, I just cleared up my development PC’s Firefox profile, and tried to install the .xpi carrying the plugin there – and on the dev PC, the plugin shows in about:plugins and runs just fine (even if it’s just unpacked in profile/extensions/EXT/plugins/obj.so, and not in ~/.mozilla/plugins)… In fact, I packaged both the extension and the plugin in separate .xpi’s, which were then merged in a single one as recommended in Multiple Item Package – MDN – and that works fine too (upon loading the merged xpi, one gets prompted about installing two extensions – one for the plugin carrying one, and the other for the “plain” extension)…

So the problem was on the other test computer only – and the problem seems to be that I’m using Gnome libraries in the plugin, and while my dev PC is Ubuntu 11.04 – I think this test PC was Ubuntu 10.04 … So, quite likely, the problem is incompatible Gnome libraries in the plugin build; unfortunately, I don’t get many errors back from firefox, even if I do:

NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile

(… as recommended in Logging Multi-Process Plugins – MDN – however, the /tmp/plugins.log remains empty). The only thing Firefox on the problem machine spits is something like this to stdout:

WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported!  This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported!  This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'

… and I cannot tell if this has something to do with the plugin or not… But I guess at least the packaging part got confirmed as working now 🙂 Cheers!

 

EDIT: After a while, the Firefox on the test PC did spit out the following (although I would have expected this message to pop up instantly):

LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]

… which finally confirms it was a build problem I have had.