Mozilla Add-ons Community Blog
Categories: compatibility developers documentation

Add-ons Update – 2017/01

6 responses

Here’s the state of the add-ons world this month.

If you haven’t read Add-ons in 2017, I suggest that you do. It lays out the high-level plan for add-ons this year.

The Review Queues

In the past month, 1,412 listed add-on submissions were reviewed:

  • 1015 (72%) were reviewed in fewer than 5 days.
  • 63 (4%) were reviewed between 5 and 10 days.
  • 334 (24%) were reviewed after more than 10 days.

There are 415 listed add-ons awaiting review.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers are critical for our success, and can earn cool gear for their work. Visit our wiki page for more information.

Compatibility

The compatibility blog post for Firefox 51 is up, and the bulk validation was run. The blog post for 52 is also up and the bulk validation is pending.

Multiprocess Firefox is enabled for some users, and will be deployed for all users very soon. Make sure you’ve tested your add-on and either use WebExtensions or set the multiprocess compatible flag in your add-on manifest.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Recognition

We would like to thank the following people for their recent contributions to the add-ons world:

  • saintsebastian
  • Atique Ahmed Ziad
  • Aniket Kudale
  • Sailesh Choyal
  • Laurent
  • Azharul Islam
  • Piyush Rungta
  • Raffaele Spinelli
  • Shubheksha Jalan
  • Rob Wu
  • euleram
  • asamusaK
  • SaminRK

You can read more about their work in our recognition page.

6 comments on “Add-ons Update – 2017/01”

  1. est31 wrote on

    Hello, and thanks for the blog post.

    May I kindly ask why bug 1328244 (link: https://bugzil.la/1328244) was labeled WONTFIX this quickly? Its understandable that you want to get rid of things like XUL where HTML can now serve as full replacement, but it doesn’t seem like you want to give any possibility to customize the UI except of coloring things differently. For most users who want to use versatile add-ons this is sadly not enough.

    Thanks for your reply, and kind regards.

    1. Jorge Villalobos wrote on

      The comments in the bug should explain the reasoning behind this. The UI changes all the time, and add-on concerns tend to slow down or prevent more radical changes. Add-ons that depend on the layout or look of specific parts of the UI are bound to easily break. The philosophy behind new APIs is that they should continue to work for as long as possible, independently from the evolution of the browser.

      1. Hammer wrote on

        “and add-on concerns tend to slow down or prevent more radical changes.”
        How changes affect add-ons was most of the time an afterthought (if at all) and they definitively don’t hold back radical changes (sure, some break). Add-ons are instead perfectly fit for prototyping and testing of radical changes before integrating them (something obviously not possible with WebExtensions).

  2. Artyom Egorov wrote on

    Yeah! My first addon is now published on AMO. Thanks to WebExtensions.

  3. Maik wrote on

    Well I’ve submitted a Thunderbird add-on 13 days ago. I’m now 208th in the queue, down from the initial 380-ish…

    1. Maik wrote on

      Submitted 21 days ago, now 126th in queue (of 324 total).