Firefox 7 add-on compatibility, and looking forward to 8

30

Firefox 7 was moved to the Aurora channel a little over a week ago, and we’re preparing to run the automated compatibility upgrade for all add-ons on AMO that are already compatible with Firefox 6. If you want to benefit from these compatibility bumps, your add-on should have a maximum compatibility of 6.* at present. If no compatibility problems are detected, we will automatically increase it to 7.* when the validation is run.

Our analysis of the bug fixes for Firefox 7 has produced the following list of notable changes for add-on developers. They are mostly XPCOM interface removals, some of them currently in use by add-ons listed on AMO. Please have a look and update your add-on code accordingly:

  • The encode and decode methods in nsIJSON have been removed. Bug 645922. This fix affects a very large portion of add-ons, so there’s an effort aiming to revert it. Either way, we strongly recommend you to use the global JSON object and the parse and stringify functions instead of the XPCOM component.
  • (Updated) The nsINavHistoryObserver and nsINavBoorkmarkObserver interfaces have changed to better accommodate Firefox Sync. Bug 633266. Several of its methods have a new parameter (a GUID). Since add-ons are normally in the observer position, this just means you get more data, so no change is necessary. Binary consumers will need to update the function signatures, though.
  • (Updated) A number of methods have been removed from the nsIDOMFile interface, notably getDataAsURL and getAsBinary. Bug 661876. Equivalent functions are available in other objects, like FileReader.
  • A few other interfaces were removed: nsIDOM3Node (bug 659053), nsIDOM3TypeInfo (bug 660539), schemaTypeInfo (bug 660539), nsIDOMNSDocument (bug 658906), and nsIDOMDocumentStyle (bug 658904).

More details can be found in Firefox 7 for Developers, as well as some new features that really exciting to have:

  • It is now possible to unload JS modules, making them a more viable option for restartless add-ons. Bug 481603.
  • Inline preferences. You can now display your preferences panel inside the Add-ons Manager, instead of using a separate window. While there are limitations to what you can do with this, it should work fine for a large subset of add-ons. Plus, it also works for restartless add-ons, which is a big win.

If there are any other compatibility troubles you have run into while testing on Firefox 7 that hasn’t been mentioned here, please leave a comment below.

Firefox 8

It’s still early to worry about Firefox 8, but there are a couple of big changes coming your way that I thought I should mention as soon as possible:

  • The nsIDOMWindowInternal interface will be removed. Bug 670235. Judging by the patch, you should be doing QI to nsIDOMWindow instead.
  • There is work being done to implement an incremental GC for the JS engine. This could potentially affect add-ons with binary components that use the JSAPI to create a custom JSClass and
    objects of that class, and the objects of the custom class have a custom GC trace function. It sounds fairly specific to actually be common, but I just want to throw this out there in case anybody is affected by it. You can contact me if you need more information about this.

Firefox 8 for developers is already available and should be growing in length in the following weeks.

Tags: , , , , , ,

Categories: compatibility, developers, documentation, general

30 responses

  1. Kyle Huey

    “A number of methods have been removed from the nsIDOMFile interface, notably getDataAsURL and getAsBinary. Bug 661876. Equivalent functions are available in other objects, like canvas.”

    This is wrong. The equivalent methods are on FileReader. This has nothing to do with canvas.

    1. Jorge Villalobos Author

      Thanks for the clarification. I learned about this change specifically from a developer who was using getDataAsURL in a way that could be similarly accomplished using canvas, namely creating a data URL from an image.

      1. Kyle Huey

        .toDataURL is a bad replacement because it blocks the main thread (and hence the UI) while it does its stuff. FileReader can do everything that the File.getAsFoo methods did … and it does them asynchronously so that they don’t block the UI.

  2. Neil Rashbrook

    Binary components would of course be affected, but JavaScript should not have to call QI to nsIDOMWindow(Internal) since XPConnect magic does that already. Note that some people might be using instanceof to distinguish between a window and some other type of object; fortunately in this case switching to nsIDOMWindow is backward-compatible.

    1. Jorge Villalobos Author

      There are many add-ons on AMO that QI to nsIDOMWindowInternal. Our interface documentation is always very lacking, and developers rarely know what they should or shouldn’t do, so they just try until it works.

  3. Matthew Tuck

    How can I benefit from being at 6.x compatibility? The auto-compatibility bump still has not run for 6.0 on my extension. These bumps every two months are getting really onerous if they never work.

    1. Jorge Villalobos Author

      The 6.* bump was run a long time ago, and the 7.* bump was run a couple of days ago. Since you’re behind in this schedule, you should read the compatibility documentation and test yourself, and then upgrade the compatibility on the site to 7.*. This way, when we run the 8.* bump, you’ll be back on the automatic compatibility process.

      We have discussed running old compatibility bumps again, but that’s not happening yet.

  4. Jeferson H.

    A XUL change in places.xul broke my extension. Filed bug 677417

  5. Wladimir Palant

    Jorge – thank you, this is very useful. Unfortunately, I already found the nsIJSON change the hard way (investigated user report about a follow-up error, didn’t find anything, noticed the original error a little bit later, figured it out and fixed the issue). It is good to learn about the more subtle changes nevertheless, will certainly save people some time.

  6. Kohei Yoshino

    Ah, as always, our Japanese translation can be found at
    https://dev.mozilla.jp/2011/07/firefox-7-compat-looking-to-8/

    Why not promote the compatibility check tool? I just came across it today.
    https://addons.mozilla.org/developers/addon/check-compatibility

    1. Jorge Villalobos Author

      You read our minds :). We’ll talk about it later today.

  7. Steve Jackson

    I was using Firefox 5 which support Norton Tool Bar. Along come a upgrade notice for Firefox 6 which I accepted but was a mistake as it does not support Norton Tool Bar. This forced me to revert back to Internet Explore 8. I hope this is fixed in FireFox 7 / FireFox 8.

  8. Katie Kalata

    I’d like to see FireFox documentation be ready when the product is released. It’s very difficult to teach students how to use the developer tools for the current browser if the training and documentation materials are not available. The training shows many good examples of how to build extensions and themes for FF4 and earlier, but not for 6, and now 7 is out on Aurora? I’m not asking for extensive material, but enough samples and documentation to use the tools.

    1. Katie Kalata

      Of course, if these do exist, other than ‘transient’ documentation that I’ve seen, please let me know I’d be happy to remove my suggestion!

      1. Jorge Villalobos Author

        Hello Katie.

        Unfortunately, you are correct, and Firefox is a very quickly moving target that is hard to keep up in the documentation area. I know the Documentation team is stretched very thin as it is.

        Most tutorials and documentation should be updated at least for Firefox 4, and the changes in 5, 6 and 7 are very small and shouldn’t affect these examples in a meaningful way. The only change to the most basic examples I can think of is that the layout in the Tools menu is a bit different and overlays should take this into account.

        If you have specific questions about add-on development, you can send me a message and we can talk about them. I’m really interested in knowing about the work you do with students. My email address is jorge AT mozilla DOT com.

        Thanks!

  9. Anh

    How can I use IDM in Firefox 7 and 8

  10. Einard

    Why is it everytime there’s a new version of firefox they are not compatible with add-on “IDM CC”? I want an immediate fix to this. You know firefox is the only browser I trust, please do have some attention with this issue before someone complains again. Thanks! More power to your new version! :)

  11. Einard

    BTW I am using the version 7 of firefox, hope this information helps.

  12. Jim

    IS FIREFOX 6 COMPATIBLE WITH DIVX 7.0?

    Thanks
    Jim

  13. Joe Y.

    Hello to all.

    I want to know, if this future version will support “Apple’s full screen apps”?

    Thanks!

  14. Mar

    Hi, I jus wanna ask is the Bitcomet add-on compatible to FF7

    FF5 isnt compatible to bitcomet so it made me go back to 4
    T_T

  15. Paul

    I cannot believe you guys removed synchronous file reading from nsIDOMFile before implementing FileReaderSync. This has broken my code and rewriting a complex cross-browser synchronous file-reading app to be asynchronous is not a small job.

    Firefox updates automatically — all my Windows Firefox users suddenly can’t use the app untill it’s fixed. This is totally unacceptable.

    1. Rick

      with my update this morning, I have various apps that are now incompatible. Very frustrating indeed!

    2. phil

      totally agree here, paul. totally unacceptable.

      my dnd upload scripts do not work anymore.
      has anyone a synchronous replacement for File.getAsBinary()? i’m pretty desperate..

    3. simon

      same here.
      annoying to say the least..

  16. john b

    can you tell us when we can expect the FileReaderSync to be implemented (7.0.2? release date?).

    thanks

  17. Jorge Villalobos Author

    There will be no 7.0.2 unless there’s a critical security problem. I’m asking around to see when/if this synchronous API will be available.

  18. Jorge Villalobos Author

    Here’s what I’ve been told: “FileReaderSync will be available in Firefox 8, but that’s only on Worker threads, so from the main thread it’s still effectively async.”

    I would appreciate it if any of you who are affected by this change would elaborate on the applications or add-ons that were broken by it. You can message me directly to jorge AT mozilla DOT com.

    1. jeff

      hi jorge

      thanks for the information.
      what do you exactly mean by “but that’s only on Worker threads, so from the main thread it’s still effectively async”? i don’t understand.. can we use FileReaderSync in FF8? do you have an example what will work and what won’t?

      keep up the great support!
      regards jeff

      1. Jorge Villalobos Author

        Hi Jeff,

        You can read about Web Workers here: https://developer.mozilla.org/en/Using_web_workers. They allow you to run code on a separate thread, so they behave asynchronously for all practical purposes.

        If you want the UI to block when performing these operations, you’ll need to introduce that block artificially.