This is a screenshot of some of my latest (and most exciting) work on my project to rewrite the extension manager. I’ve just implemented support for a special kind of extension that can install (and uninstall, and enable, disable, upgrade and anything else you can think of) without the user needing to restart Firefox. This is of course to allow add-ons developed on the Jetpack platform to install without restarts but the feature is going to be available to any extension author, there are just some restrictions to how these extensions work.
19 thoughts on “Look Ma, no restarts!”
Hi…ETA is FF 3.7?
Yeah the idea is that these extensions will still load in the normal way on versions of Firefox that don’t support this.
Actually, now that I think about it – what you are describing means that no overlays will be applied automatically. Which means that you have to track new windows being opened and manually apply overlays to them. Some way to manipulate the internal overlays table would be better – analogous to what is usually done by chrome.manifest but with the ability to add/remove overlays dynamically while the application is executing (maybe some new methods on nsIToolkitChromeRegistry).
Yeah this is part of what I meant about right now this being pretty raw and ready. Once this is in I expect we’ll start looking at things we can add to the platform to make using this kind of thing easier on developers.
Blair McBride posted a link to the code and I got my answers from there. Suggestions:
* Don’t use a regular object a scope for the bootstrap script. If that script tries to access global variables/functions it will get them from the scope of the extension manager module. As far as I know, the only way (from JS) to give this script a truly self-contained scope is using a Sandbox object: |let scope = new Components.utils.Sandbox(“chrome://global/content/”)|. Of course, the Sandbox object isn’t meant for that but it works well.
* Don’t reload the bootstrap script every time you need to call one of its methods, make it persist. So rather than storing dir.persistentDescriptor in bootstrappedAddons, store the scopes of bootstrap scripts. This way the scope will only be released when the add-ons are disabled/uninstalled and replacing XPCOM components from “classic” extensions will be a lot simpler.
Yep, the code there is just an early implementation, using a simple object was just a hack because there was no-one around on the weekend to remind me of the right way to do that 😉
Not reloading the bootstrap is a good point, should be pretty simple to make that the case.
Better late than never. This “feature” has been on Google Chrome for a long time. You better speed up your “copying” unless you (firefox) wanna stay relevant…
Not quite, only newly created Chrome tabs get the extensions. Tabs that were running before an extension was installed don’t get the new extension, because of the very limited way Chrome extensions work.
Exciting news! Keep up the good work 🙂
Will we also also themes to install and apply without a restart?
If someone were to fix the bugs relating to applying themes without restarting then yes we could switch this on for themes.
This goes by the name of Dynamic Theme Switching on the tracker, for those interested.
Also related, from the above:
Dave, thank you for implementing my suggestions – starts looking really good.
Just out of curiosity: is there a particular reason you use |for (let i = 0; i < methods.length; i++)| rather than |for each (let method in methods)|? Somehow I always assumed that the latter is slightly faster because it immediately stores the member in a local variable rather than requiring you to access it by its index. But with TraceMonkey you cannot really know.
It’s true it is basically safe in this case though.
I see. I prefer to keep Array.prototype alone and to strictly separate “arrays” and “maps”. But in your case it isn’t all under your control of course.
Comments are closed.