- #What is mozilla firefox packages install
- #What is mozilla firefox packages code
- #What is mozilla firefox packages Pc
- #What is mozilla firefox packages zip
and I cannot tell if this has something to do with the plugin or not. (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' WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
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! as recommended in Logging Multi-Process Plugins - MDN - however, the /tmp/plugins.log remains empty). 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
#What is mozilla firefox packages Pc
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. 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). In fact, I packaged both the extension and the plugin in separate.
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).
#What is mozilla firefox packages install
xpi extension.īasically, I just cleared up my development PC's Firefox profile, and tried to install the. 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. just an install.rdf and plugin in /plugins), only extension gets shown - no plugin (and no reasonable error messages). but if I try the same with my FireBreath plugin (e.g. 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. How would I go about this kind of packaging thing - is there a recommended way to do it?Įdit: 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, referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.
so to ~/.mozilla/plugins/ however, I would like to spare the user of that :) Now, of course, the user could themselves symlink the extension.
#What is mozilla firefox packages code
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. xpi, try to install it on a different computer.
#What is mozilla firefox packages zip
then I zip the whole extension directory (the plugin included) as an. and then insert the following in chrome.manifest: binary-component plugins/linux/npXXX.so ABI=Linux_x86-gcc4 So I try to copy the plugin file to plugins/linux inside the extension directory: cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/ ( There is also mention of " /platform", but it clearly says it's been deprecated for Firefox > 3.6). 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. 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). 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)īinary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3 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, knowing that " firefox supports installing your plugin via XPI. 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 :) The resulting plugin on this platform is an " npXXX.so" file, which I got symlinked in ~/.mozilla/plugins. I'm working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. 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.
0 kommentar(er)
