Add-ons Update – Week of 2013/06/05

6

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

  • Most nominations for full review are taking less than 4 weeks to review.
  • Most updates are being reviewed within 10 days.
  • Most preliminary reviews are being reviewed within 10 days.

These stats are taken from the last queue report:

  • 119 nominations in the queue awaiting review.
  • 106 updates in the queue awaiting review.
  • 101 preliminary review submissions in the queue awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 22 Compatibility

The compatibility blog post for Firefox 22 is up, and the compatibility bump for AMO add-ons will be run probably next week. Firefox 22 is scheduled to be released on June 25th.

As usual we recommend using the Aurora and Beta branches to test your add-ons ahead of time.

Firefox 25 Compatibility

There are some pretty big changes coming up in Firefox 25, so I did an early post on it. Please give it a look.

Tags: , , , , , ,

Categories: compatibility, developers, documentation

6 responses {+}

  1. waheed

    Thanks all of you..

      ·   Reply

  2. Mingyi

    Is there some problem in validating Addon SDK based addons today (June 9)? I tried to submit new versions of two of my addons, one was a simple repack, and neither got past “Add New Version” dialog. It stopped at 100% validation complete message, but “Add Version” button remains grayed out.

      ·   Reply

    1. Jorge Villalobos Author

      Yeah, that’s this bug. It’s planned to be fixed today.

        ·   Reply

  3. Mingyi

    BTW I really wish that the Firefox API (XPCOM in particular) is more stable. I wrote one Chrome addon, never had to change a thing for years and it just work. Granted, my Chrome addon doesn’t use the powerful and complicated XPCOM like my FF addons do, and the XPCOM changes might be mandatory sometimes.

    But I’d really appreciate it IF the compatibility changes of XPCOM comes with full examples of how to get back the lost functionality with alternatives. Like, for example, it took me a while to find out how to replace faviconService.getFaviconForPage partly because the compatibility for FF22 page you posted said to use Places.utils, but that page had no examples how to replace this (or if I can use it in SDK-based addons). More searches turns out the mozIAsyncFavicons alternative, which the doc page said to use queryInterface to get, no need to get another service. But in the end I use getService just like any other service to get it.

    Things like this really do not make things easy for authors of multiple FF addons – a little more doc on these things would go a long way to avoid authors to eventually abandon the maintenance of their addons. I actively maintain my addons closely, but it’s definitely takes much time already just to add features/remove bugs. Please make our lives easier by providing better docs whenever you guys change XPCOM that forces us to patch our addons. Thanks.

    Now I assume I’d have to spend the next hr figuring/testing how to replace nsiglobalhistory2…

      ·   Reply

  4. Mingyi

    Well, not to be a pest, but it didn’t surprise me that the Places doc’s much welcomed full-detail examples about history services (https://developer.mozilla.org/en-US/docs/Places_Developer_Guide#Adding) were entirely outdated. Every single alternative listed there, if you go to their respective doc pages, were marked as obsolete since Gecko 22. This really isn’t helpful to addon authors …

      ·   Reply

    1. Jorge Villalobos Author

      Yes, our documentation story is less than ideal :(. If you need help figuring anything out, please ask in the forums or the #extdev channel on IRC.

        ·   Reply

Post Your Comment