Mozilla Add-ons Community Blog
Categories: compatibility developers documentation policy releases

Add-on compatibility for Firefox 4 – time to get started

25 responses

As most of you are already well aware of, Firefox 4 Beta 1 was released a few weeks ago. Beta 2 will follow very soon, and the final version is expected late this year. This relatively long transition period is great for add-on developers, because it gives us plenty of time to update and test our add-ons for Firefox 4. On the other hand, this new major release is going to sport a ton of new features, and it will break a great deal of stuff we need, so it won’t be trivial to upgrade most add-ons to support it. This is the first of many posts that inform add-on developers about Firefox 4 compatibility.

First of all, MDC is your friend: Firefox 4 for developers. This is the document that will and should have all the necessary information for web developers and add-on developers surrounding Firefox 4. Make sure you visit this document regularly and look for changes. If you know of anything missing in that document, please add it yourself or let us know.

Here are some highlights from the document.

The new Add-on Manager object

The nsIExtensionManager interface is no more, along with its RDF backend. Add-on data will now be stored in a SQLite database, and the Add-on Manager is now a JS Module called AddonManager.

A key difference in this new interface is that requesting add-on data is now asynchronous. This applies to the FUEL library as well, so every add-on that requests add-on data is affected. This is particularly delicate for add-ons that have to fetch and deal with this data at startup. However, if you’re also trying to follow our startup performance recommendations, you should already be planning on implementing an asynchronous startup process.

XPCOM Registration

There’s a lot going on in this area: XPCOM Changes in Gecko 2.0, and none of your components will work until you adjust to these changes.

Components now need to be explicitly declared in the chrome.manifest file. A number of startup observer topics have been removed, leaving only the one that has always been recommended: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed.

Changes to tabbrowser

The TabClose, TabSelect and TabOpen events no longer bubble up to the tabbrowser element, also known as gBrowser. Event listeners for these events should be added to gBrowser.tabContainer.

Remote XUL is going away

Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL instead of HTML. Since XUL support is limited to a few browsers, it didn’t make much sense to create websites with it. However, it has been used successfully in a small number of internal business applications (also known as ‘dark matter’).

Remote XUL has been a big maintenance problem, and it has been the source for numerous bugs and security problems. For this, remote XUL will be removed in Firefox 4. Luckily, HTML 5 already includes a fairly robust box model, so the main loss here is that web developers will not be able to use XBL anymore. If you’re wondering what happened with XBL 2, removing remote XUL is a necessary step to work towards implementing it.

Theme and UI changes

This is an area where you need to check back frequently, because there are many ambitious plans for the Firefox 4 UI. Whether some of these changes will be implemented or not depends on time and finding the right compromises.

The main document for these UI changes is in the Mozilla wiki: UX Priorities for Firefox 3.7. Some important changes you should know about:

  • Tabs on top. There will be a preference that controls the location of the tab strip and toolbars.
  • App menu. On Windows (at least?), there will be a single menu button instead of the full menu toolbar. Pressing the Alt key will toggle the “classic” menu. This will surely have an impact on add-ons that overlay menus in the Main Menu.
  • Home tab. This is a fixed tab in the first position of the tab strip.
  • App tabs. It will be possible to toggle tabs into app tabs, which basically means they can’t be easily closed and their titles will be hidden, only showing the favicon. More interesting changes, like hiding toolbars for these tabs, are being planned.
  • There are talks around hiding or completely removing the statusbar, another significant change for add-on developers. The discussion has spanned a number of blog posts, and will surely continue. For more information, please read parts 1, 2 and 3.

Other Stuff

  • For performance reasons, Firefox 4 is now caching some resources more aggressively, including extension chrome and JS files. This can lead to unexpected behavior when developing an add-on because changes to some files will not apply unless the corresponding cache files are deleted. This is the relevant bug. Please don’t comment on it just to show support for either side; there’s too much of that already. In a nutshell, you should make sure that you have all the right preferences set and you use the -purgecaches command line argument when running your development profile. This will still fail to update your JS Modules, but this should be fixed in a future build.
  • User Agent strings are going to be minimized for various reasons. In order to align with these efforts, AMO Editors will soon be looking for UA manipulation in extensions. We will forbid any unnecessary modifications. Unless your add-on really needs to change the UA, you should start removing this code.
  • I was informed by a developer that dropping a URL into the sidebar now has the default behavior of trying to open this URL. If you handle drag and drop in your sidebar, make sure you use preventDefault.

As you can see, there’s plenty of work to do in order to become compatible with Firefox 4, so this is a good time to begin. However, keep in mind that Firefox 4 is still very much a work in progress, and there are likely more changes to come. Don’t think that you can create a final version of your add-on for Firefox 4 just based on the first beta. My recommendation is that you take your time and make sure you stay up to date with Firefox 4 news.

And, of course, there’s plenty of good stuff coming that will enable you to do amazing things in your add-on, including 2D and 3D animation, multi-threading and interaction with system libraries. Firefox 4 for developers is, again, your friend. The Hacks blog also has a nice overview.

Update: the second installment of this series was published a few days ago.

25 comments on “Add-on compatibility for Firefox 4 – time to get started”

  1. Brett Zamir wrote on

    While not perfect, fans of XBL might consider working with (and improving) the XBL2 JavaScript implementation: http://code.google.com/p/xbl/

  2. Michael Kaply wrote on

    I’ve started putting together code samples for the new add-ons manager if folks want to add to it:

    https://developer.mozilla.org/en/Addons/Add-on_Manager/Code_Samples

  3. Philip Chee wrote on

    How about UA Spoofing extensions that are used to allow Firefox to log into sites that do bad browser sniffing?

    Phil

    1. Ms2ger wrote on

      These, by definition, don’t change the UA string *unnecessarily*.

      Also, FWIW, HTML5 doesn’t provide a box model; CSS does. In particular css3-flexbox provides features that were formerly limited to XUL.

  4. Mook wrote on

    profile-after-change wasn’t was not always recommended, app-startup was (because profile-after-change wasn’t a category name until Firefox 3.5, and lots of things still try for 3.0 compatibility).

    Removing XBL(1) has nothing to do with implementing XBL2; it’s purely a security decision. At least, I have not seen any indications of that being the case (since XBL2 is basically independent and in a separate namespace).

    Theme changes are still too early, there’s more things to land. Last I heard the plan was for another month (but probably more?) of betas (and requiring approvals to land, which hurts everybody else).

    Re: XPCOM changes: How do I override a contract ID dynamically, and forwarding things to the old implementation (essentially wrapping it) so only behaviour I specifically care about get modified?

    Re: UA: http://geckoisgecko.org/

    Re: ChromeWorker: The documentation ( https://developer.mozilla.org/en/DOM/ChromeWorker ) is ridiculously sparse. Shouldn’t it at least indicate what are the new accessible global objects? How do I get to js-ctypes if it requires finding a ctypes.jsm?

  5. Joe wrote on

    XPCOM Changes:
    What about xulrunner-sdk(s)?

  6. Christopher Finke wrote on

    Is there any documentation on programmatically converting a normal tab into an app tab?

    1. Christopher Finke wrote on

      Found it: gBrowser.pinTab(tab);

  7. toto wrote on

    XPCOM changes in Gecko 2.0

    I’m trying to upgrade an extension I’m working on.
    It uses an XPCOM library aborting with this error number 0x80570016
    I think the reason is that I compile my library with Gecko 1.9 so this don’t work with FX4.

    I can’t find the (beta?) version of gecko 2.0 :
    https://developer.mozilla.org/en/Gecko_SDK

    Where it is ?

    Thanks

    1. Denise Atchison wrote on

      i cant even get on the internet they are saying that i need to check my proxy and my firewall and i have fire wall but i cant still get on the internet so now am wanting you to install this firewall i cant read my e-mail so it wouldnt do any good for you to e-mail me. Please install for me !

  8. Jorge wrote on

    @Philip Chee: that would be allowed, of course.

    @Ms2ger: you’re right about CSS being the one providing the box model.

    @Mook: my comment about XBL2 is based on this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=546857#c14. The missing documentation will hopefully begin to appear as time progresses. Like I said, it’s still early.

    @Joe: I believe this won’t be mandatory for xulrunner applications, but I’m not 100% sure about that.

    @Christopher Finke: I haven’t seen any docs, but I guess it’s just a matter of identifying the right command for it.

    @toto: looks like there’s no compiled SDK distribution yet, you would need to compile it from source.

  9. Matthew Wilson wrote on

    As far as I can see, nsIPref has been removed, after being deprecated for some time.

  10. Chris wrote on

    please add the ability to modify the grey bar on top of themes. like in google chrome. also add slide tabs animation and a better status bar.

  11. umuthan wrote on

    where we can find beta add-ons for firefox 4 beta1?

  12. Jason Barnabe wrote on

    Is there any documentation on how to get command line options working again in Firefox 4? Phillip Chee asked for this in http://blog.mozilla.org/addons/2010/06/14/multiple-breaking-changes-are-coming-for-components-in-extensions/#div-comment-94771 . This is the only thing I haven’t been able to fix in my extension, Stylish.

  13. Bobby Jack wrote on

    Do you know what the thinking is behind the ‘menu button’ change? Is it just a case of copying other browsers, or is there an argument in its favour? I’m concerned, for usability reasons, that this is a change that’s inconsistent with other applications the user will be familiar with (see URL for more details).

  14. Winnorf wrote on

    I cannot stand for the bookmark icon to be on the right in version 4. When 4 beta two came out, I had problems with the tabs that I could not fix with re-installation. Re-installed 3.6. Don’t really know where to complain.

  15. Raphael wrote on

    @Jorge is it expected that FF 4 will break many existing add-ons? I noticed the code I use to manipulate #contentAreaContextMenu (the native FF context menu) no longer works. Without the use of Firebug, it’s a little painful to troubleshoot further. Is there a place where I can read on expected incompatabilities with proposed fixes?

  16. Jorge wrote on

    @Raphael: yes, the changes introduced in version 4 are significant, and add-on developers need to track its development closely in order to stay up to date. It’s inevitable that many add-ons will break when the final versions are launched.
    You can use the Add-on Compatibility Reported to force compatibility for any add-on. This may help you run Firebug, unless it really breaks.

  17. Arifa wrote on

    Should we make any changes in the xul manifest files such that they support XPCOM?

  18. CodeMachine wrote on

    I managed to get everything obvious compatible with Firefox 4 quite easily. There were a few minor issues but nothing terribly difficult to deal with.

    Compared to the massive breakage that was Firefox 3, which plagues me to this day, this is a breeze.

  19. Walid Damouny wrote on

    The problem with Firefox extension compatibility is that they are based on the version number string stored inside the extension. Even though an extension might function flawlessly on newer/older versions of the browser it is still disabled when the string doesn’t match.

    What Firefox needs is something similar to the “using” directive in C++

    using namespace_name;

    Now you are all shouting at me. I can hear that in my mind, but forgive me for I haven’t written any extension yet. I believe that the whole of XUL is available to an extension which is good but leaves the programmer having to revise all used APIs and tag that extension with some handcrafted version compatibility string that might be inaccurate or even plain inconsistent if an API call was skipped.

    Since the “using” directive in C++ is enforced if used and this behavior is probably inconsistent with today’s Firefox approach, another convenient turnaround can be implemented. Use an external tool that does the checking of called APIs before submission to the add-ons site and rechecked after submission to sidestep badly coded extensions. Place this info in a dependencies file along with the extension and get rid of the version compatibility string. This will enable a browser to know for sure if an extension is compatible or not and not rely on an arbitrary number or string set by hand.

    The beauty of this approach is that both user and developer will instantly have a clear view of what works and what doesn’t. This will help developers get their extensions ready without a full revision or even bothering them just to change a string if it works already and also prevent users from having to enforce compatibility of incompatible extensions and use trial-and-error to figure out what works.

  20. Byungwook Kang wrote on

    Hello,

    Addon manager in Firefox4.0b8pre gets blank, if I install WebMail Notifier with some addons.(DOM inspector or Session Manager).
    If I install WebMail Notifier alone, this does not happen.
    I found that this happens when I call ‘onStateChange’ in ‘nsIWebMailListener’.

    Please help me.

  21. herbert wrote on

    Context menu is indeed broken so does the drop down box from which you can choose stored username, etc. Please fix.

  22. rest wrote on

    which version of real player allows us to download videos from mozilla 4 ?