Mozilla Add-ons Community Blog
Categories: compatibility developers documentation releases

Add-ons Review Update – Week of 2010/08/03

9 responses

Summary

  • These bi-weekly posts 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 posted in this blog that should be read as a general guide about the review process.
  • Most nominations are being reviewed within 3 weeks.
  • Almost every update is being reviewed within 1 week.
  • The Mozilla Summit and the Firefox 4 beta launches have delayed reviews noticeably. Major version releases trigger an unusually large number of new submissions and updates.  We’re catching up at the moment, but things will be slow for the time being.

The Review Queues

  • The stats are taken from the latest queue report from last Friday.
  • 170 nominations in the queue awaiting review.
  • 98 updates in the queue awaiting review.
  • 835 reviews were performed by the AMO Editors in the month of July.

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

Firefox 4 Compatibility

Firefox 4 is coming later this year, and beta 2 is currently available for download. This will likely be the most difficult upgrade path for add-on developers in the history of Firefox, so everybody should keep an eye on beta updates and all the documentation that will be published around them. At the moment these are the most useful documentation resources:

I’ll do my best to keep everybody up to date with breaking changes in Firefox 4, but I don’t want to bombard you with information. I might post a new extensive update in the beta 3 or beta 4 timeline. In the interim I’ll use these reports to post all the new (sometimes unconfirmed) feedback I’ve received, with as much information I have at hand. Here are the notes I have so far:

  • Toolbar buttons are (for now?) a different size. Toolbar buttons now have a different look and a different size at least on Mac and Windows, but it is unclear if they will remain this way. Michael Kaply filed a bug about it and there’s an ongoing discussion happening over there. Like I mention in the Firefox 4 Compatibility blog post, the UI is the most volatile part in the 4.0 update, so it is not a good idea to rely on how it is in its current state. If you want your toolbar icons to look right in current betas without spending too much time, you’ll need some CSS trickery. Chrome manifest flags are very useful for these kinds of hack.
    • Mr. Kaply also contacted me recently about the toolbar button changes and asked me if I thought this should be stopped because it would place a bigger burden on add-on developers. I don’t think it should. This is a major update, and I don’t think it’s all that surprising that it comes with a revamped user interface. This should be done with minimal breakage if possible, but I don’t think that changing toolbar icon sizes is such a dramatic change as others already listed in the documentation. I guess he interpreted my answer as an “I don’t care” and wrote this blog post accusing us of not voicing the concerns of add-on developers. I may be wrong about the magnitude of this situation, though, and I’d like to hear from the community about how difficult it would be to maintain a new set of icons with different sizes, how many of you actually hire graphic designers to do your icon work, and how many of you don’t use vector graphics to generate your icons (I mean GIMP and Photoshops projects and the like, not SVG).
  • Toolbar customization. There’s a bug in toolbar customization that can revert changes performed by users. There’s also a weird bar that appears under the toolbars after customization at least on Mac OS. Note that the bug can be triggered by add-ons that access certain browser features before the onload event is fired. If this is the case for your add-on, please read the comments carefully.
  • From Mook: How do I override a contract ID dynamically, and forwarding things to the old implementation (essentially wrapping it) so only behaviour I specifically care about get modified? Is this something that the new XPCOM registration method won’t support?
  • From Christopher Finke: app tabs can be toggled using gBrowser.pinTab(tab);
  • The new Gecko SDK is still not available in the MDC page. Developers that use binary XPCOM have to build it themselves from source (bad).
  • From Matthew Wilson: after being deprecated for a while, the nsIPref interface has been removed.
  • From Jason Barnabe: command line options on the new XPCOM registration system are currently undocumented.
  • From Raphael: the content context menu is broken.

Notes for Developers

  • How to Improve Extension Startup Performance. All extension developers should read this blog post. It explains how extensions can have a significant impact in startup performance and, some very simple steps you can follow to minimize this impact. There’s also a link to some tools that can be used to easily measure startup.
  • New Proposal for Review Process and Delightful Add-ons. This is a new and different approach to resolve the issue of add-on safety in the sandbox and code reviews. All add-on developers should read this and give feedback. It’s been a long process to try to find the right balance of the many elements involved, and we think this is it.
  • 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.
  • AMO is currently being migrated to a new code base, some of which is already live in production. If you notice any strange behavior on the site , please make sure to file a bug (see note below about AMO bug reporting).
  • Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.
  • Bugzilla information for editors. How to file AMO bugs, how to flag bugs relevant for editors, and information on current and future AMO version releases. Let me know if you want to help fixing AMO bugs.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

9 comments on “Add-ons Review Update – Week of 2010/08/03”

  1. Michael Kaply wrote on

    @Jorge,

    I did not interpret your response as an “I don’t care,” I interpreted it as “no.” I asked this question:

    > I’m just wondering if folks on your team are advocating at all for
    addon developers or just letting the changes happen?

    And your answer was more of a “letting the changes happen.”

    What I want to know is if the AMO team participates in Firefox meetings and says “How will that impact add-on developers?”

    Is anyone advocating for add-on developers, or are we on our own?

  2. Ben Bucksch wrote on

    > I don’t think that changing toolbar icon sizes is such a dramatic change
    > as others already listed in the documentation. I guess he interpreted
    > my answer as an “I don’t care”

    I would interpret “I don’t think [it] is such a dramatic change” as “I don’t care” as well :).

    FYI, it *is* a drastic change. If you are a coder and ever tried to do a non-trivial application, you’ll notice that you’re kind of stuck with the icons and they take tons of time. if you work for a company, usually you get the “artwork” from another department, and working with “another department” always means major hassle, in almost any company.

    Given that even FF4 itself is inconsistent between the platforms, there’s no way an extension developer can supply the right icon, even if we were to go back to arts department.

    Scaling bitmaps is a no-go. Esp. small ones. Often they are hand-optimized.

    You may make nice, new, fresh, innovating new themes, with a totally different look. You must keep certain basic assumptions, though, e.g. whether the border is in the icons or not, and which size the icons have. That’s given, set in stone, and cannot be changed in years. You have to work with what you (and we) have.

    In this case, you *can* work with what you have. No problem to use icons in 16×16 size instead of 18×18.

    There’s “absolutely need to” breakage, and there’s “I don’t care about downstream” breakage. The XPCOM registration stuff was the former due to electrolysis, I guess. The icon stuff is the latter.

  3. Jorge wrote on

    @Michael Kaply:

    It’s my job to be one of the voices (if not the only voice) of add-on developers at Mozilla. I’m a developer myself and I know what all of us have to go through to update our add-ons.

    I will certainly protest against any update that unnecessarily affects add-on developers, like the fast cache situation: https://bugzilla.mozilla.org/show_bug.cgi?id=531886. I won’t comment there because it’s already a flamefest, but I’m closely tracking that issue. I just don’t think that toolbar button sizes are even in that category.

    And no, I don’t sit on every Firefox meeting to see if something is ever mentioned that could affect add-on developers; that would be a waste of time most of the time, for me and others. I do get updates on upcoming breaking changes through other channels, although I admit some of them arrive a little late.

    I don’t think we’re on our own, and I still don’t think that changing the theme in a major version update is such a horrible imposition on developers.

  4. Michael Kaply wrote on

    I apologize for misinterpreting the original email.

    But based on your response, I still believe there is a problem in the Mozilla process. It doesn’t sound like anyone says when changes are suggested “how will this affect addons.” It sounds like it’s an “after the fact” kind of thing.

    What can we do to be more proactive?

    And I’m sorry, but I don’t think you really understand the icon situation. You need to read the bug. Scaling icons is wrong. And creating 18×18 or 20×20 icons is not a solution. Addon developers should not have the burden of creating 4 or 5 different sized icons and having to write code to make then version and platform dependent.

  5. Jorge wrote on

    No need to apologize, I can see how my response could have been read that way.

    As for being proactive, it’s a difficult thing to do. I don’t think it’s constructive to have an ‘add-ons’ person on every meeting just waiting to see if something will have an effect on add-ons. Platform developers should be aware of which changes affect the Mozilla API, given that they are required to document these changes. I think that this is a step they tend to neglect, and it’s part of the reason that MDC can be lacking in many areas. Maybe it’s about educating developers and being more pushy about their disclosure of breaking changes.

    And I’m not saying that scaling is right. I’m suggesting it can be worked around in the meantime with CSS, either by scaling or just adding some padding to the small icons. If the current sizes actually make it into Firefox, developers will need to transition having to double their icon sets in order to cater to both sizes. I know this is a lot of work, but if there’s a real reason for these UI changes, I think they should be done eventually. If this is nothing more than an oversight from the UI designers, then it’s better to keep the previous dimensions. That’s my take on the matter.

  6. atj wrote on

    Are there snapshots of the Gecko source available somewhere? I found the hg repo but at ~950M it’s far too big a dint in my monthly quota to consider. As an aside, it strikes me as a bug that the toolbar icons can’t be SVG (or similar) which would make their size largely a moot point.

  7. Michael wrote on

    Looking at the content of this blog post and the links, this all seems a bit of a mess. Not that this is your fault, but the documentation is all spread out and has links to blogs, newsgroup posts and ongoing discussions.

    Maybe it’s my imagination, but my feeling is that at this point in previous releases that was all done, and https://addons.mozilla.org/en-US/firefox/compatibility (is that going to be updated) was counting up the compatible addons.

    Seems like on this trajectory Firefox 4.0 is going to be released with few add-ons being compatible, which will frustrate everyone (well, at least everyone who uses add-ons) and hold back upgrading. Because of those issues in the past, add-on compatibility was made into a major goal for the previous couple of releases. Now that all seems to have gone away again 🙁

  8. Mook wrote on

    For the thing I mentioned: Pre-XPCOM-2.0, you could, in NS_GetModule, look up the old classid before registering your contract id, and use the old classid to instantiate the old component as appropriate.

    In the new world, your registration happens by reading chrome.manifest and you don’t get a chance to run any code (e.g. to look for the old classid). While it’s possible to hard code the Firefox-as-shipped classid, 1) you can’t be forward-compatible, 2) two people trying to do this will fail.

    This may or may not matter in reality (I imagine few people do the odd things I tend to do), though?

  9. Jorge wrote on

    @atj: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0b2/source/

    @Michael: keep in mind that the release process for Firefox 4 is very different from previous versions. The plan is to have many frequent beta releases (beta 3 is coming up very soon), as opposed to just having a few and then moving to RC. The final release of 4.0 is still scheduled for late in the year, so there should be plenty of time for add-on developers to work on this. The main problem in this new system, IMO, is that many users expect add-ons to work with betas, so much more work is demanded from us to keep up with this fast pace.

    @Mook: I’m pretty sure that very few add-ons do this, but it’s important to have it documented somewhere. Thanks for expanding on it.