I blogged a short time ago about how we’re adding support for a new form of add-on to Firefox that can install and uninstall without needing to restart the application. Since then I’ve been finalizing a specification for how the platform will load these add-ons, trying to keep it simple but still give developers everything they commonly need. The planned specification is now available and if developers have comments then I’d like to hear them. Currently there isn’t a version of Firefox that implements it but that should change in the next day or so when I make the changes to the add-ons manager project branch and very soon when it all lands on trunk.
My hope is that once on trunk this spec won’t change but obviously this is quite new so we may see changes for a short time if add-on developers come across problems.
As usual, I will add the comment about themes: Themes are ‘restartless’, they only need a refresh of the main window. See the ‘Switch Themes’ extension by Pardal Freudenthal to see how this can work.
Just integrating this extension into the Firefox base, adds ‘restartless’ to theme installation/switching.
It is not really clear what “Whenever an add-on needs to be loaded” means and what exactly the authors code in bootstrap.js should be doing.
Thanks, I’ve added an additional section and tried to clarify the wording for consistency, let me know if it makes things better.
Clear yes, thanks.
Do you plan to have some types of add-on restartless (and without the requirement for the bootstrap.js file) by default?
I’m thinking about themes, like already mentioned in a previous comment, but also about spellchecker dictionaries.
Potentially yes
Numbers in APIs are so 20th century: how about passing the |reason| values as strings so our code is simpler?
The spec also needs to tell us about the state of the system during these calls. For example, we need to know if |uninstall| is always preceded by |install|.
We need to know what this means:
Note that install will never be called if the add-on is never loaded.
since the spec describes install and startup but not ‘load’.
I’m not sure why code is simpler with strings, and comparing against fixed constants has the benefit that if you mistype the constant in your code you’ll see a JS error warning you about it. With strings it isn’t the case.
The clarifications I’ve made should answer all your questions I think.
“The add-on must at this point do anything necessary to make its functionality available, the platform not execute any other part of the add-on. ”
I guess a word is missing.
Thanks, fixed
Sorry, now I realize there is a pretty fundamental question:
We currently initialize when the browser.xul is loaded (actually we have to hack a delay to allow the XBL to initialize correctly). Now we should use startup()? What state is the application in when startup is called? browser.xul is loaded? our scripts in overlays are compiled? our overlays are added to the browser.xul but the js that backs the controls is not attached (because we have not initialized)?
The application may be in the middle of starting up (no browser window present) or it may be already up and running. Your code should use the window enumerator to find if there any windows that you need to add UI to or wait until such windows are opened. You have to handle loading overlays etc. yourself, the platform will not do it for you if you switch to this type of add-on.
Ok, even though it seems obvious to you I think it would be good to say this on the wiki, since it’s a critical difference one needs to know up front.
“In order to do this, rather than the application loading chrome and components from the add-on it is up to the add-on developer to do all of this manually.”
This is an excellent idea, we are waiting for this feature !
We can already manually load / unload chromes, load / unload resources aliases (nsIResProtocolHandler.setSubstitution(“xxx”, null))… But I don’t find a way to unload jsm modules (xpcIJSModuleLoader.idl). Do you know if there is a project for unload and reload jsm modules ?