Mozilla Add-ons Community Blog
Categories: compatibility developers documentation

Add-ons Update – 2017/02

11 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,670 listed add-on submissions were reviewed:

  • 1148 (69%) were reviewed in fewer than 5 days.
  • 106 (6%) were reviewed between 5 and 10 days.
  • 416 (25%) were reviewed after more than 10 days.

There are 467 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 blog post for 52 is up and the bulk validation was already run. Firefox 53 is coming up.

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:

  • eight04
  • Aayush Sanghavi
  • zombie
  • Doug Thayer
  • ingoe
  • totaki
  • Piotr Drąg
  • ZenanZha
  • Joseph Frazier
  • Revanth47

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

11 comments on “Add-ons Update – 2017/02”

  1. Mark Smith wrote on

    Question to Mozilla Devs: Why not allow existing add-ons which use XUL etc to be used indefinitely into the future, and only require newly written extensions to use WebExtensions? This would grandfather in old extensions while encouraging WebExtensions for new code. Dropping XUL is going to destroy your user base .

    1. Jorge Villalobos wrote on

      (Not really a Mozilla dev, but involved in the decision process) Many changes are coming up that will break them anyway, so it’s more a question of whether the breakage will be controlled and more easily communicated to users and developers, or a series of breaking releases that will be frustrating for everyone. Neither are great options, but we decided it was best to go with the former.

  2. Clara wrote on

    Where is vimperator in this queue? It’s been many days, and basically that’s the only add on that keeps me and a very large amount of people using firefox.

    1. Jorge Villalobos wrote on

      It’s near the top of the queue, but due to its complexity it probably needs an admin reviewer to give it a look. Currently, their plate is fairly full, so it might take a while.

  3. clunky wrote on

    The stats look great, but how do waiting times of several months fit into this picture? Example (initially there was a justifiable delay due to a security issue): https://github.com/bitwarden/browser/issues/8

    Side remark: your email form refuses to accept valid email addresses (e.g. letters like $ and € in the user part do not work).

    1. Jorge Villalobos wrote on

      Long waits are in the minority, but we do recognize that waiting times for those add-ons can be significant (months, sometimes, like you point out). We have some plans to improve waiting times, but they’ll take some time to deploy.

  4. Igor wrote on

    For me, 22 days and counting…

    My extension’s queue position was going down until it reached position 10, day after that it regressed to position 12 and haven’t moved since. I’m stuck at that position for at least four days now.
    I can see that total items in the queue move up and down all the time, so it feels like queue is not reviewed by first in – first out order?

    1. Jorge Villalobos wrote on

      Add-ons aren’t reviewed strictly first-in-first-out, since different reviewers have different experience levels. Add-ons that make it so far up the queue are usually reserved for admin reviewers who deal with the most complex ones. Those add-ons are the ones that take the longest to be reviewed because we only have two admins working through all of them.

      1. Igor wrote on

        Thanks for the answer. It makes more sense now.

      2. Raymond Hill wrote on

        Just a thought.

        I wish the reviewing of extensions on AMO was crowdsourced — this way I would definitely contribute as time permits. I imagine a way for anybody to jump in and being able to comment on any one extension in the queue, and the ability to vote as to whether an extension appears to be ok for publication.

        Virtuous side-effects of a crowdsource approach:

        – openness of the whole process of reviewing;
        – the spreading of good practices to a wider audience — anyone could read the recommendations, points of concerns, corrections, etc.;
        – low barriers to entry for anybody to contribute on a completely voluntary basis;
        – spreading the workload which would help a lot these queue issues.

        What would be required for a crowdsource approach:
        – all extensions in the review queue being open to public (except maybe for rare exceptions);
        – A differ tool readily available for code in need of review;
        – A comment system to freely comments on whatever portion of code.

        Sort of like what GitHub offers, anyone can comment on any commits, but completely geared toward the purpose of greenlighting extensions.

        Of course there would need to be rules so as to avoid noise in the comments — these would need to be strictly relevant to the review process.

        1. Jorge Villalobos wrote on

          Thank you for the suggestions. There are some issues regarding opening up the queues and add-ons for easy inspection, mostly because of confidentiality of source code and release dates for certain add-ons. We’ve never made the queues public in part because of that.

          We are moving to a different review model for WebExtensions, but that’s still being designed. We will certainly stop blocking publication on reviews in the future, at least for most add-ons.