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:

There are disadvantages as well 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.

Tags:

Comment [3]

  1. Chris Finke · 2012-07-12 15:51 · #

    How do you go about debugging memory issues in restartless extensions? Occasionally, I’ll have zombie compartments left (according to about:memory?verbose) after uninstalling, and while I know in general what to look for in the code, it’s trial and error at best.

    Reply from Wladimir Palant:

    That’s one advantage I forgot to mention – you actually notice it when you leak memory because compartments belonging to your extension stay around after you disable it. Debugging memory leaks is always a bit tedious but with about:ccdump (https://addons.mozilla.org/addon/cycle-collector-analyzer/) it is quite doable. You get the CC data, look through the sandboxes in the list, identify the one belonging to your extension (the compartment that leaked) and display the roots for it. Then you have to understand why that root is connected to your extension (current version of about:ccdump doesn’t make that step easy enough, I am saving the log and processing it with my own script).

  2. Manuel Reimer · 2012-07-12 18:01 · #

    I followed all your blog posts about “restartless extensions” and for me it definitively seems to be a bad idea to do this.

    Many things have to be done in own code, that would be handled by the backend code, otherwise, like overlay loading, component registration and many more.

    In my opinion, Mozilla addon development already has a very steep learning curve, but with restartless, it gets even steeper.

    I’ll keep my addon (PrefBar) the way it is until the whole process of porting to “restartless” gets simplified a lot. In my opinion, the whole restartless thing is primarily optimized to be used with “Jetpack” and not to be used by the average addon developer.

    Reply from Wladimir Palant:

    Yes, at the moment some things require more work than necessary and aren’t good enough for newbies. But we are mostly talking about relatively simple code that is easily generalized. I do hope of course that this code becomes part of the platform in future (e.g. component registration for restartless extensions can be easily made part of XPCOMUtils).

  3. Tobu · 2012-07-15 15:49 · #

    s/even after disabling/because after disabling

    I didn’t understand it right the first time, I took it to mean that showing compartments after disabling was done on purpose rather than a symptom and only got it after seeing your next post.

    Reply from Wladimir Palant:

    I’ve slightly adjusted that passage, hopefully it is easier to understand now.

Commenting is closed for this article.