Why you should make your next add-on restartless · 2012-07-12 14:18 by Wladimir Palant
Note: This article is not about extensions based on the Add-on SDK (Jetpack). You don’t have to use the SDK to create a restartless extension. Just wanted to point this out explicitly to avoid confusion.
An extension that will install without requiring a Firefox restart? This was a nightmare to develop not too long ago. Fortunately, things changed and the last showstopper bug was fixed in Firefox 8. Effort to create a restartless (or bootstrapped as it is called officially) extension is acceptable now. In fact, I have converted all my extensions and removed support for classic non-restartless extensions from my build tools — I am certain that I am not going back.
So, how did it go? It was a mixed experience actually. The new extension type has significant advantages:
- The user experience is simply better. It is nice to install an extension within a second and to continue doing whatever you’ve been doing before — no restarting the browser, no session restore. And it also helps a lot if the user experiences issues: disable the extension, check whether the issue is gone. Takes only a few seconds.
- Testing a restartless extension during development is easier. Do you still use complicated test environments so that you can test changes without restarting the browser? Do you keep in mind which parts of your extension can be updated this way and which ones still require a browser restart? I simply use Extension Auto-Installer to update the extension in the browser instead — it’s fast and I actually test the same build that my users will get later.
- A simple extension is simple. Classic extensions require you to create numerous files and a directory structure. A restartless extension doesn’t need more than the install manifest (
bootstrap.js) in the same directory.
- You have a centralized and logical place to run your code. The
bootstrap.jsfile gives you a single environment that will be around for as long as your extension is enabled. Compare that to classic extensions where most extensions use overlays as a trick to inject scripts into the browser window. And then they struggle attempting to synchronize the code instances in different windows, e.g. by abusing preferences for something that doesn’t need to be persistent.
- You actually own the environment where
bootstrap.jscode runs. You don’t have to worry that another extension will declare a variable with the same name — you are not in a shared environment, only your own code executes here.
- If your extension leaks memory or doesn’t clean up after itself properly you will notice — because even after disabling the extension and minimizing memory use
about:memory?verbosewill still display a compartment belonging to your extension (thanks to Chris Finke for reminding me, I originally forgot listing this point). Investigating the memory leak will still be tedious but at least you will know it is there.
There are disadvantages as well however:
- Converting an existing extension can be rather complicated, especially when it comes to user interface integration. In particular, making Adblock Plus restartless turned out way more time-consuming than I expected. This is of course easier if an extension is restartless from the very start.
- The platform mechanisms used for restartless extensions aren’t quite as well-tested as for the classic extensions. I didn’t notice it when I published my first eight restartless extensions, but Adblock Plus with its millions of users is a bug magnet of course. So I very soon discovered bug 770669, rediscovered bug 744833, and there seems to be yet another similar issue that I didn’t manage to reproduce yet.
- Many tools and helpers that the Gecko platform provides you with weren’t built with extensions in mind that can come and go at any time. So in many cases you will have to take a more complicated route and do things manually that should normally be handled by the platform.
- You cannot use XBL. And you have to append a random parameter to the URL when loading string bundles. Such annoyances will hopefully get less as the platform is improved.
- The documentation is unfortunately not very helpful. MDN has lots of examples and tutorials but those tend to ignore features that are less than five years old. You will get several detailed tutorials on creating classic extensions or using overlays but not a single one will mention even the existence of restartless extensions or the Add-on SDK. You have great code snippets for common tasks but these never use new and highly recommendable helpers like Services, FileUtils or NetUtil. Even the XPCOM examples were occasionally ignoring XPCOMUtils or using an approach that stopped working when Firefox 4 came out (I think that I got the important ones fixed however).
For me, the advantages clearly outweigh the disadvantages. If you already have a classic extension then you may wait with converting it until you actually have time for that. But if you are planning a new extension then you certainly should make it restartless. I consider the complete lack of documentation the biggest problem right now — MDN needs to shift its focus from classic extensions to restartless extensions. I want to publish a few articles on how I solved the typical problems, this will hopefully be a good start.
Commenting is closed for this article.