Add-ons Review Update – Week of 2010/12/22

1

Summary

  • These posts written every 2 weeks explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process that should be read as a general guide about the review process.
  • Most nominations are being reviewed within 10 days.
  • Most updates are being reviewed within 7 days.

The Review Queues

  • The stats are taken from the latest report at the forum.
  • 64 nominations in the queue awaiting review.
  • 76 updates in the queue awaiting review.
  • 537 reviews performed by AMO Editors this month. There were 13 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Firefox 4 Compatibility

Firefox 4 will be released early next year, beta 7 is currently available for download, and beta 8 will be coming very soon. This will be the most difficult upgrade path for add-on developers yet, so everybody should keep an eye on beta updates and all the documentation that is being published. At the moment these are the most useful documentation resources:

Beta 7 was the first release after the codebase went through feature freeze. This means that no major changes are going to be performed, and add-ons that work correctly on beta 7 are very likely to work in the same way until the final release. Here are some pending issues of Firefox 4 compatibility that haven’t been addressed in other blog posts:

  • Since toolbar buttons are very important for developers and button sizes changed for Firefox 4, I wrote this analysis of toolbar buttons and icons in Firefox 4. One problem was brought up in the comments, which triggered the creation of bug 616472. This bug, if fixed, will change the way toolbar buttons are created for Firefox 4 (again), so you should track this bug if it affects you. I’ll post an update once the bug is resolved.
  • The Add-on Bar is supposed to appear automatically when a button or other items are added to it. This isn’t working at the moment, but it is being tracked on bug 616419. In the interim you can force the bar to appear the first time you add your button.
  • The requires tag in install.rdf will not be supported in Firefox 4.
  • Firefox 4 no longer creates child HWNDs for internal use, which breaks a few binary add-ons and accessibility tools that relied on this quirk.
  • Regarding the problems with Thread Manager and the lack of alternatives, I’ve had some useful conversations with Mozilla engineers, and we’re trying to reach a solution. I’ll be writing more about this in the following days.
  • Finally, if you want to help fellow add-on developers with a simple bug fix, here’s one that’s up for grabs: Addon object not passed to custom about dialogs. Fixing this will be very helpful for developers who have their own custom dialogs and don’t want to mess around with the asynchronous Add-on Manager API and the reflow problems that can arise from changing XUL content dynamically. Update: a patch was already submitted. That was quick!

Benjamin Smedberg wrote a post about reusing a Jetpack component to run JS code in a separate process. As it is now expected from any form of separate processing, there’s no XPCOM access and all communication happens through message passing. Actually, I don’t really know what’s the difference between this and ChromeWorkers.

Notes for Developers

  • Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
  • The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
  • Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

Tags: , , , , , , ,

Categories: compatibility, developers, documentation

One response

  1. Nils Maier

    The difference between JetpackProcess and ChromeWorkers, as I understand it, is that ChromeWorkers are actual threads within the same process, while JPP is an actual process outside of the main process.
    Hence if you crash a JPP only the JPP will be gone (you can even restart it). Think Out-Of-Process plugins, like Flash, that, when they crash, do not crash the browser itself; while ChromeWorkers will take your browser down with them if something crashes.
    Both have ctypes enabled, so both are crash-prone.
    ChromeWorkers are, however, more lightweight. Starting a new process takes time, IPC/message passing between processes takes time, JPP will likely consume a lot more memory.

    My understanding is: You do something “simple” and safe, like XHR or js math you’re likely better of with a ChromeWorker. Using ctypes you’re likely better off with JPP.