Mozilla Add-ons Community Blog
Categories: compatibility developers documentation

Add-ons Update – Week of 2015/04/29

3 responses

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 9 weeks to review.
  • 126 nominations in the queue awaiting review.
  • Most updates are being reviewed within 6 weeks.
  • 48 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 9 weeks.
  • 127 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 38 Compatibility

The Firefox 38 compatibility blog post is up. The automatic AMO validation will be run soon.

Expect a compatibility post soon about a special 38.0.5 Firefox release that will follow 38.0. I don’t think this will break any extensions, but it might affect themes and it’s a heads up so you can test on beta in advance of the release.

Firefox 39 Compatibility

I expect to publish the Firefox 39 compatibility blog post this week.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) 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.

Extension Signing

We announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. If you’re an extension developer, please read the post and participate in the discussions. A followup post was published recently, addressing some of the reasons behind this initiative.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running each content tab in a different one. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

3 comments on “Add-ons Update – Week of 2015/04/29”

  1. Ben Bucksch wrote on

    > The automatic AMO validation will be run soon.

    Do you mean the signing validation?

    We need a few months transition period between when the AMO automatic signing method for third-party extensions is implemented, so that we can automatically sign our ext, and when the signature is actually required in Firefox for installation of the ext.
    It is a massive process change on our end. The currently available information is not sufficient for us. A lot depends on the concrete implementation on the Mozilla side. For example, we don’t know whether our extension will pass the automatic tests, which makes a difference of 6 weeks (see above numbers), which makes a huge difference in our release process. Until we know that for certain, we can’t make a release plan for our ext. It needs to be fully implemented in AMO, including the concrete tests that will be run, for us to adapt to it.

    1. Jorge Villalobos wrote on

      > Do you mean the signing validation?

      No, I mean the Firefox 38 compatibility validation.

  2. BINSniper wrote on

    Our 3.0 release sat in queue for 3 months, eventually climbing to 9th position, where it sat for about a month. Since it was looking like it might take a year or more to get it reviewed, we submitted 3.1 and we’re now back at position 71.

    I realize that the queue isn’t processed in order. But it seems that a large number of addons were reviewed while we sat stuck in queue. Are there certain technologies that are delaying reviews? We migrated to framescripts in 3.0.

    It would be nice if new versions didn’t reset the queue position if the extension is already in queue.