Add-on Compatibility for Firefox 8

22

This post is long overdue, I apologize for the delay. We ran the Firefox 8 compatibility bump last Friday (August 26th), and while there are still a few bugs to fix in this system, the validation was mostly successful and we automatically upgraded roughly 3000 add-ons.

Here are the add-on compatibility-breaking bugs I identified that have been fixed in Firefox 8, currently in the Aurora track:

  • Remove ISO8601DateUtils.jsm. The Date object now supports the capabilities this module provided, so there’s no need for it anymore.
  • Remove nsIDOMWindowInternal. This change affected many add-ons, so it was reverted. However, the interface is deprecated and may be removed in the future. We added a compatibility warning explaining that nsIDOMWindow should be used instead.
  • document.getSelection() should return the same as getSelection(), not stringification. This changed the return value of document.getSelection so that it matched window.getSelection. Instead of a string, it returns an object now.
  • Merge nsISelection* interfaces. A couple of relatively obscure interfaces were merged into nsISelection. The latter should be used instead.
  • The implementation of the File API introduced one global called File, which could conflict with objects in your scripts. We learned about this change after the bump, but it would have been very difficult to create a validator check for this anyway. It would’ve been too noisy. If you have globals named File, you should rename them.
  • In the same vein, a global named ChromeWorker was introduced. There’s no validation for it, but no add-ons are affected as far as we know. This constructor was introduced instead of the XPCOM interfaces that existed before it, like nsIWorkerFactory. Most of this work is detailed in this bug. We learned about this change after the fact as well, but we don’t expect many add-ons to be affected by it. Please let us know if this affects you.
  • Remove SSL 2.0 support. This doesn’t affect any current add-ons, so we didn’t add validation for it. It just means some very old code was removed, as well as these preferences: security.enable_ssl2 (false by default) and security.ssl2.*.

Here are a few other changes that probably interest you but don’t break compatibility as far as we can tell:

As always, there’s more detailed information in Firefox 8 for Developers. If there’s anything missing here or in the MDC page, or if you had any problems with the latest compatibility bump, please let us know in the comments.

We’re also streamlining the breaking change detection process, and I posted in the newsgroups about this: Keeping add-ons compatible in the rapid release process. Please have a look and let us know what you think.

Tags: , , , ,

Categories: compatibility, developers, documentation

22 responses

  1. Ian Thomas (thelem)

    > Remove nsIDOMWindowInternal. This change affected many add-ons, so it was reverted.

    I think this is the first example I have seen of the rapid release process actually making the upgrade cycle easier. With the old process it would have been a bit hit or miss whether the impact of removing this feature would have been realised, and there could easily have been a major release of Firefox without the feature. Once that happens, it’s unlikely to be put back in as a point release, so the extensions would be forced to change their behaviour.

    The rapid release process has forced add on compatibility scanning, meaning the issue could be spotted and avoided before a major release happened.

  2. Kohei Yoshino

    As always, Japanese translation can be found at
    https://dev.mozilla.jp/2011/09/add-on-compatibility-for-firefox-8/

    1. Jorge Villalobos Author

      Thanks!

  3. -_-

    Really should have a minversion for compatibility as otherwise users may try to get their favorite old extension from Firefox 2.0 working and then wonder why Firefox is not working right or such.

    1. Dwn

      But anything might break with every release in the rapid release process, that’s why the major version gets bumped.

  4. Dwn

    What about compatibility meta information for global installs?

  5. Gabriel Levy

    The ChromeWorker change is affecting us. We have a bootstrapped extension and were using nsIWorkerFacory to create a ChromeWorker. As this no longer works, we are not sure how to spawn a ChromeWorker from bootstrap.js on FF8. Calling “new ChromeWorker” gives “Exception calling callback: ReferenceError: ChromeWorker is not defined.”

    Speaking more philosophically, the decision to eschew any kind of commitment to API stability seems rather callous. I’m all for a more agile development cycle, but gratuitous interface changes make life very difficult for developers. I’m no expert on XPCOM internals; perhaps it was impossible to leave the working interface in place and just tie it in with the new ChromeWorker code. However, in light of the aggressive push to move people off of XPCOM binary components and to ChromeWorkers/js-ctypes, it would be nice if those considerable efforts yielded some security for more than several weeks.

    1. Jorge Villalobos Author

      You should be able to create a ChromeWorker like this:
      let worker = new ChromeWorker("script.js");
      Doesn’t this work for you? Where are you running this code?

  6. Gabriel Levy

    This running in a bootstrapped extension (aka restartless addon) as described here:

    https://developer.mozilla.org/en/Extensions/Bootstrapped_extensions

    Specifically, in the startup() function within bootstrap.js, we spawn a ChromeWorker:

    function startup(data, reason) AddonManager.getAddonByID(data.id, function(addon)
    {
    ….
    if (Components.classes["@mozilla.org/threads/workerfactory;1"]) {
    // Firefox 4-7
    var workerFactory = Components.classes["@mozilla.org/threads/workerfactory;1"]
    .createInstance(Components.interfaces.nsIWorkerFactory);
    var worker = workerFactory.newChromeWorker(“resource://shmcert/worker.js”);
    } else {
    // Firefox 8+
    var worker = new ChromeWorker(“resource://shmcert/worker.js”);
    }
    ….
    }

    However, the call fails with this error:

    Warning: WARN addons.manager: Exception calling callback: ReferenceError: ChromeWorker is not defined
    Source File: resource:///modules/XPIProvider.jsm ->…

  7. Gabriel Levy

    Jorge, any word on ChromeWorker change?

    1. Jorge Villalobos Author

      Hi Gabriel.
      I’m sorry, I haven’t had time to look into it, but it’s definitely on my list of things to do. I just want to come up with a couple of minimal testcases to make sure the bug is there and then be able to file it correctly.

      1. Gabriel Levy

        OK, thanks for your help. I’ll stay tuned.

    2. Jorge Villalobos Author

      I just filed bug 690418 and copied you. Sorry for the delay.

      1. Gabriel Levy

        Much appreciated, thank you.

  8. Archaeopteryx

    Date.parse offers less than ISO8601DateUtils.jsm, it doesn’t parse datetime strings with local timezone offset like 2011-10-04T17:52:00+0200, filed https://bugzilla.mozilla.org/show_bug.cgi?id=693077 for this.
    A second issue is the new tab tearing which doesn’t yet use the drag and drop API, see https://bugzilla.mozilla.org/show_bug.cgi?id=674925 and https://bugzilla.mozilla.org/show_bug.cgi?id=690227

    1. Michael Kaply

      In addition, creating ISO dates is hideous. The ISO8601DateUtils had a nice create function.

      Was there a technical reason this was removed? Or did someone just believe that Firefox had enough support?

  9. Anders Eriksson

    Not sure where to post this, as I have a hard time finding any site about making your own Firefox themes (not personas).

    Anyway, I have a very simple toolbar theme, based on Patrick J Dempsay’s recoloured 4.0 he put up on the theme site a while back. I replaced some of the icons and used it for a few months.

    Now with FF8 it’s not loading the toolbar image. Did anything change regarding the install.rdf structure or the chrome.manifest?

    In my manifest file I have the single line
    “override chrome://browser/skin/Toolbar.png Toolbar.png”
    But Firefox is not doing the replacing.

    Any help or pointers to how the theme is supposed to be changed would be much appreciated.

    /Anders Eriksson

    1. Jorge Villalobos Author

      There shouldn’t be any difference. I think the best place to get help for themes is the Mozillazine Forums.

  10. Sherrie

    I am a novice at viruses. I had my first 4 last night. I deleted firefox, but it is my favorite searcher (not sure that is the technical name). Last night I was not able to access my email but if you can please respond to me that would be awesome. I really want to use firefox, but saw something about some kind of virus with ff8 and something about how to repair it on the blog. Can you please help me. Obviously I know how to install it, but I don’t know what or how to do whatever it is to not get the virus again.
    Thank you so much, Sherrie
    BTW you will be writing Katie…she is my wonderful niece :D Thank you so much.

  11. Aubz

    My prefbar add on for Firefox 8.0.1 was working fine until this morning when a forced update, even though I had that option turned off, broke prefbar, What is going on here? Where do you guys get off playing with my computers setup? Do you want to be replaced by chrome? The only, repeat, only reason I use Firefox is the add on collection. Take that away from me and I am out of here!

    1. Jorge Villalobos Author

      What do you mean by a forced update? Does the problem still occur?

      We’ve had some server problems, as explained in this blog, and this has caused some problems related to the compatibility data that Firefox requests from the Add-ons site. This could explain the problem, and it should be fixed now.

  12. yohi

    my extension provides openDB api to create sqlite database in profile folder. am able to use it from DOM environment. but while trying to call it from webworkers throwing error as it was undefined