From release 0.99+1.0RC1-3, a new scheme for extensions has been implemented in Mozilla Firefox packages. It follows the behaviour the -register option of Firefox should have had from the beginning, while keeping the old broken scheme.
In 1.0-1 and subsequent releases, support for old scheme is dropped.
In 1.0-3 (not yet released) and subsequent releases, /var/lib/mozilla-firefox/locales.d is ignored.
For users, it means that we'll hopefully avoid a lot of problems because of the way Firefox handles extensions.
For maintainers, it means moving around some files, and being happy with the new scheme. If maintainers don't do that, their extension/localization will just be ignored by Firefox.
Since version 0.9 (IIRC) of Firefox, upstream has implemented a (pretty broken) Extensions Manager [EM] that tries to regulate how extensions are installed and how compatible they are to the current Firefox running.
That improved user experience if they were installing extensions in their user profile, but has been a pain in the ass for maintainers, since there was no real support for stuff installed by something else than Firefox (in Debian case, dpkg).
So, while upstream pretended to implement some supposedly cool stuff for us, it was just a vain expectation that is still waiting to be solved.
Anyways, the main conflict with our old approach and the new EM, is that even if the EM sees that an extension is too old and not compatible and should be removed/disabled/whatever, all the files we provide are still registered in the chrome, through files in /usr/lib/mozilla-firefox/chrome and /var/lib/mozilla-firefox/chrome.d.
Same kinda applies with components and other things, but the main difference with chrome is that they don't overlay stuff in Firefox potentially breaking things if the browser-base changes.
So basically, the main change is that the support for /var/lib/mozilla-firefox/chrome.d has been totally dropped, making files in /usr/lib/mozilla-firefox/chrome useless.
Another change is that defaults and components registration now works (as from 1.0-1), while it was not functionnal in 0.99+1.0RC1 releases.
Just switch to the new scheme, you'll see, it's actually a lot easier.
First, your upstream might have added an install.rdf file in its .xpi or whatever for a while now.
Look into this file, in the section under <Description about="urn:mozilla:install-manifest">, the value for <em:id/>. This is the UID of your extension. Be aware that if it ever changes upstream, you'll have to move your files accordingly ; it won't work otherwise.
An extension MUST provide the following files :
(Be aware not to forget the {} characters in the UID).
An extension SHOULD provide the following file :
[DEPRECATED from 1.0-3] A localization MUST provide the following file (in addition to the standard extensions ones) :
If an extension provides preferences files, it MUST provide them into the following directory :
(Preferences files can be links to files in /etc, though. /etc/mozilla-extensions is the recommended location in that case)
If an extension provides components files, it MUST provide them into the following directory :
For the rest of the files, the current location where you put them is probably the only solution.
This is the install.rdf provided in the upstream .xpi.
This is the jar file given in a <em:file/> section, in <Description about="urn:mozilla:extension:file:xxxxxxx.jar">. Note there can be several jar files, but usually extensions come with only one.
Contains the following :
type,UID
where type is either extension or theme. That means extension applies to both extensions and localizations.
This is recommended to provide this file because it will be created anyway by Firefox (it is needed), but won't be removed from the system if the UID directory is a link. The link will be deleted before update-mozilla-firefox-chrome gets called, meaning that Firefox can't know where the files it created are.
It can be a good thing to install the exact file that Firefox would create, for tools keeping track of checksums, if any.
Contains the following :
langcode:variantcode
where langcode is the language code (e.g. en, ja, pt, etc.) and variantcode the language variant code (e.g. US in en-US, JP in ja-JP, BR in pt-BR, etc.)
Note: from release 1.0-3 of mozilla-firefox this file isn't needed any more. IT was used by the firefox startup script to auto-detect which language to use depending on the curent locale. From release 1.0-3, the internal locale auto-detection mechanism of firefox is being used (yes, there is one, and it was not activated by default. The option isn't even in the default preferences files coming with upstream source...)
Most (all ?) of the recent .xpi files already expose the directory tree which has to go in /usr/lib/mozilla-firefox/extensions/UID for defaults, components, and chrome, meaning you almost have nothing to do, except creating some files in /var.
If your extension/localization only contains chrome, set Depends to
mozilla-firefox >= 0.99+1.0RC1-3
or, depending on how your dependencies are, set Conflicts to
mozilla-firefox << 0.99+1.0RC1-3
If your extension/localization also contains defaults and/or components, set Depends to
mozilla-firefox >= 1.0-1
or, depending on how your dependencies are, set Conflicts to
mozilla-firefox << 1.0-1
If your localization doesn't provide the deprecated file in /var/lib/mozilla-firefox/locales.d, set Depends to
mozilla-firefox >= 1.0-3
or, depending on how your dependencies are, set Conflicts to
mozilla-firefox << 1.0-3
You can take a look to the mozilla-firefox-dom-inspector package (version 1.0-1 and subsequent), it is a full extension package with defaults, components and chrome.
You can also take a look at my mozilla extensions (see my QA page and look for checky, ctxextensions, diggler, livehttpheaders, tabextensions) in their latest release.
You can also take a look into venkman, which should be soon uploaded to unstable, and can help you debugging problems with extensions (the dom inspector is quite useful as well).
Localization packagers can also take a look at my update of the mozilla-firefox-locale-ja package (well, I wanted to have the japanese locale to go with my japanese desktop)
If your extension only provides a component (i.e. no chrome at all), you will have to put it into /usr/lib/mozilla-firefox/components. Registering an extension (with install.rdf) without chrome is not supported (but I'm wandering if it might not be worth implementing, since it would provide users ability to disable these components).
Last update: Sun, 14 Nov 2004 14:29:42 +0900