How many hacks does it take to make your extension install without a restart? · 2010-09-10 15:50 by Wladimir Palant

Dave Townsend did some really great work on the add-on manager recently, he managed to completely rewrite the old crappy backend code and replace it with something far more sane. Along the way a new feature was added: starting with Firefox 4 some add-ons should be able to opt-in and install/uninstall without requiring a browser restart. This feature was primarily meant for JetPack-built extensions but is generally open to all other extensions as well. I tried enabling this feature for Adblock Plus and found that there is an awful number of catches attached to it. I wrote these down, might save somebody else’s time:

At this point my hack-o-meter exploded and, as you all well know, programming without a functional hack-o-meter isn’t safe. So I decided to give up on this whole idea, I probably spent too much time on it already. I’m pretty certain that there are more catches that I just didn’t find yet. And — sure, if your extension is very simple (in particular: minimal user interface) things might work out for you. After all, it works for JetPack and they only use a few of the hacks I mentioned.


Comment [6]

  1. Dave Garrett · 2010-09-10 19:21 · #

    Thanks for this wonderful summary! I suggest making a new meta bug on Bugzilla to cover this mess, in addition to the specific bugs you’ve already filed. Hopefully if the right people are poked nicely enough this will progress in a direction towards sanity. ;)

    For me, I’ll update Flagfox to be restartless as soon as the hack-fest mentioned above is whittled down to a reasonable level. The only ones that don’t really apply to me are the XPCOM catch as Flagfox uses JSM and some portions related to overlays, as I already do quite a bit dynamically and could probably hack in without an overlay if push came to shove.

    My sympathies for your poor dead hack-o-meter.

  2. Alex Vincent · 2010-09-10 19:32 · #

    On point 3, could you use a local scope object?

    var myLocalObject = {};
    Components.utils.import(…, myLocalObject);

    When I saw point 1, I said “that’s not for me.” :-p

    Reply from Wladimir Palant:

    Will that scope object be of any help? It is still the scope object of the module from the previous extension version and there is no way to make Firefox load the new module if the file name stayed the same.

  3. Dave Townsend · 2010-09-10 21:27 · #

    Thanks for spending the time and energy to go through this Wladimir. I’m sad that we’re clearly not yet at the point where complicated extensions like yours can be made restartless but having this list of issues is fantastically useful.

    Reply from Wladimir Palant:

    Yes, it is really too bad – at some point I actually thought it would work out (when I got a dialog to work from my frankenchrome protocol). You’ve done some nice work but there are still too many assumptions in the platform that break if add-ons can come and go at any time. Btw, I forgot to mention catch 6.5: The new add-on manager won’t accept extension icons from non-chrome protocols and options/about dialogs from non-chrome protocols open as content in a new browser window (which isn’t even resizable). This behavior is new, things work fine in Firefox 3.6. There must be some hardcoded check for chrome where it should be looking for URI_IS_LOCAL_RESOURCE protocol flag but I couldn’t find it when I looked at the code briefly.

  4. Jorge villalobos · 2010-09-10 21:58 · #

    I think #5 is really the non-starter. Anything other than a handful of trivial scripts with little to no UI won’t work. I was considering testing a few new extensions I had in mind as no-restart, but I expected that creating new windows would be possible (without jumping through so many hoops).

    Thank you for the detailed post!

  5. Justin Dolske · 2010-09-11 10:52 · #

    This is really great work, it’s important to be exploring the boundaries of what’s reasonable with restartless addons to help guide us for what needs addressed.

    One thing I would add is that a lot of these “hacks” are, basically, the core of why restartless addons have taken so long to come into being (even in the current limited form). There’s a lot of stuff baked into the platform that assumes certain things don’t change during runtime / without a restart. Careful design work needs to be done to determine which things should be fixed-up to work, and which things need fundamentally redesigned.

    Also, kudos for what I’d call a model post of constructive criticism. Nary a positive thing to say here, but nonetheless engaging, actionable, and makes me excited about potential things to improve in Mozilla. More, please!

  6. jSully · 2010-11-06 05:48 · #

    <Sigh> Wish I’d found this post sooner!

Commenting is closed for this article.