Add-ons Update – Week of 2014/04/16

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 3 weeks to review.
  • 148 nominations in the queue awaiting review.
  • Most updates are being reviewed within 2 weeks.
  • 118 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 2 weeks.
  • 142 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 29 Compatibility (Australis!)

This is a big one. The Firefox 29 compatibility update is here, and there are some additional posts explaining some of what’s new:

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

The Add-ons for Australis contest is now closed, and we have begun the judging phase. We will announce the winners on this blog in a couple of weeks. Good luck!

12 comments on “Add-ons Update – Week of 2014/04/16”

  1. Peter wrote on

    Had to wait in the queue for 3 weeks (!). Meanwhile a Chrome extension is distributed within 30 minutes. Maybe you should look into automating the review process…

    1. Jorge Villalobos wrote on

      Automating the review process makes the system very insecure, so that’s not an option for us. It’s unfortunate that we’re a bit lacking in volunteer support at the moment, but we thinks it’s the best way to ensure a safe experience to our users.

      1. Luke wrote on

        Glad to have a real person reviewing these, it keeps quality up and prevents spyware/adware apps and renamed ripoffs of common open-source apps, as we see in Google Play.

        By the way, any results yet from the Firefox 29 redesign contest that ended this week?

        1. Jorge Villalobos wrote on

          We’re only starting with the judging period. It’ll take a couple of weeks before the results are published.

      2. Peter wrote on

        Well, human reviewers are not exactly more secure. For example one of your reviewers approved an update of my add-on. In the next update, which only included some minor tweaks, another reviewer denied the update for a reason the first reviewer approved. Because of this, and the waiting period of 3 weeks between the reviews, several thousand users have an add-on installed that was labeled as insecure by Mozilla.

        Of course there is no actual security problem in the add-on. The reviewer criticized the lack of escaping two variables. However those variables are set by the add-on (not the user) and can’t cause problems. But as the second reviewer put it: they don’t have time to look at changes in context.

        In the end I agreed to escape the variables and pushed another update. At the current speed of the queue I wonder if 3 weeks of waiting will be enough. On many days it doesn’t move at all. To remind you: in the meantime all users are using the old version which was first labeled secure by the first reviewer and then insecure by the second reviewer. And of course the users miss out on the new features, some of them being support for Australis.

        For some add-ons this slow and cumbersome process might work. For others it doesn’t. I can see why some devs decided to self-host their add-ons.

        If you keep simply denying the need for (at least partial) automation I can only shake my head. Especially with the Add-on SDK you created a platform that can be used as a starting point.

        1. Jorge Villalobos wrote on

          There is some automation in the preliminary validation we perform. However, we can’t leave the manual review portion aside, since there are plenty of problems that are either very difficult or impossible to detect automatically. The manual process certainly isn’t perfect, since there’s clearly a human element at play, but it’s better than nothing, which is the only viable alternative at present.

          We’re working on reducing waiting times. Hopefully they’ll be back to more acceptable numbers soon.

      3. S Antony wrote on

        I second what Peter said. And there must be some process to speed up add-on review times.
        I had a similar experience. After nearly 20 days, my add-on was only granted prelim-review due to a style sheet loading convention (I was supposed to escape the css with -moz-document despite having unique ids for all the elements). I immediately corrected and re-submitted. But I don’t think it will get reviewed any time in another 2 weeks, as the queue is quite big now.

        1. If there are minor problems like these, (or as in the case of Peter above), I think the rules could be relaxed a bit. Unless, it is a critical problem, the add-on could pass the review and the author can be given comments to correct and re-submit. Is there a reviewer’s dashboard that can track such things ?
        2. There must be some way to indicate that updates to a reviewed add-on is only a minor one. I had this experience when the only change was one line of json string, and still I had to wait around 2 weeks. Yes, a ‘minor-update’ switch could get abused, but doesn’t reviewers do a diff with the previous versions ?
        3. I guess many people would happily volunteer to test other’s add-ons so as to get their own add-on reviewed quickly. Although not everyone can review, testing with a pre-defined criterion should still be possible.

        My 2 cents.

        At the end, I understand that reviewing an add-on is a really time consuming process, and I thank all the volunteer add-on reviewers out there!

        1. Simon wrote on

          I agree with the sentiment of some of these comments, especially Peter and Anthony.

          I sincerely don’t believe some further automation couldn’t help a bit, at least to triage slightly, but i’m willing to accept that could be just a reflection of my own ignorance.

          Further, making small changes shouldn’t lose ones place in the queue. And making changes as per the reviewer requests shouldn’t cause you to go the end of the queue, though i’m no where close to even getting a preliminary review yet.

          1. Jorge Villalobos wrote on

            Yes, we agree that submitting new versions while in the queue shouldn’t set you back. There’s a bug opened to fix that. Unfortunately, development on AMO is fairly stalled at the moment, so we need to prioritize very aggressively.

  2. Fil-an Garcisto wrote on

    Ok

    1. Fil-an Garcisto wrote on

      Its great

  3. Iman wrote on

    Maybe chrome extensions are reviewed so quickly, but you need to pay 5$ to be able to publish your addons, that’s not a lot of money but the problem is that this money should be payed with a Google wallet, and if you want your payments to be processed you need to prove your identity, for people like me (I’m leaving in Iran and my country and USA don’t have good relation ships), it’s impossible to publish an addon there. It just looks stupid. I rather publish addons for firefox.