Mozilla Add-ons Community Blog
Categories: developers end users

Add-on Metadata & Start-up Time

13 responses

One of the best features of Firefox 4 is the entirely re-designed Add-ons Manager that displays more details than ever before about the add-ons you have installed. Screenshots, ratings, reviews, detailed descriptions, and even support for Contributions are all included. In order to power this feature, Firefox checks the AMO API once a day to ask for any updated information about your add-ons, including add-ons that may not be hosted there.

We love add-ons and want everyone to discover how customizable Firefox is, but we also know there are some add-ons that cause extreme slowdowns in Firefox because of poor coding practices, in extreme cases adding 30 seconds to start-up time. Unfortunately, we usually don’t learn about these problems until it’s too late and already affecting a large number of users. That’s why we recently modified the daily add-on metadata ping in Firefox 4 to also include how long it last took Firefox to start up. With this new information, we can identify add-ons that are causing significant performance problems in Firefox before they become widespread problems, and work with the developer to correct the issues.

User control and respect for privacy are fundamental to Mozilla’s mission, which is why we’ve explained this in the Firefox Privacy Policy and offer an easy way for users and developers to opt out of this metadata ping.

We hope you enjoy these new features of the Add-ons Manager and look forward to improving the Firefox experience for users with slow add-ons installed.

13 comments on “Add-on Metadata & Start-up Time”

  1. Michael Kaply wrote on

    The URL on how developers can opt out doesn’t work

    https://developer.mozilla.org/Addons/Working_with_AMO

    1. Justin Scott (fligtar) wrote on

      Hmm, I guess removing the locale doesn’t work like I expected. Try https://developer.mozilla.org/en/Addons/Working_with_AMO

      Thanks

  2. Mook wrote on

    Hmm. How do I go about opting out of the sending of extraneous data without disabling automatic addon updates? That is:
    – I don’t want to send my startup timings
    – I *do* want to check for addon updates.
    – Not actually implemented, by ideally I’d want to randomize the list of addons it’s requesting updates for so it’s harder for AMO to know what I have. Sort of like what the safe browsing code does. Of course I realize the chances of that happening is basically zero :p

  3. Jesper Kristensen wrote on

    I would assume Firefox only queries AMO if it is set as the update server for the addon. Is that correct? What happens if I have included a custom updateurl? Will Firefox ask my custom server instead, and how do I implement that on my server side, or will it just not display this extra information for my addon?

    1. Justin Scott (fligtar) wrote on

      This metadata is separate from the updateURL. Firefox will still check for updates at the updateURL. This API request will only go to AMO.

  4. Tom wrote on

    Can addon developers see this information? This would be useful as we make performance improvements over time to be able to see the average times per version number of our addon.

    1. Chris Finke wrote on

      Ditto. I’d love to see this data integrated into the statistics dashboard for each add-on.

      1. Ken Saunders wrote on

        Ditto to his ditto

    2. Johan Sundström wrote on

      Seconded. We can currently scrape the subset of this data off of all AMO add-on pages with public stats (such as Greasemonkey) and try to aggregate it together to approach that data, but the unfiltered feed would be a lot more valuable.

      Trying to answer important questions like “why does my add-on’s usage dip over weekends?” is hard when you only have your own data, but easy when you can see that it’s because all of Firefox (desktop?) is used less over weekends (a trend 4 % units weaker for FF users with at least one add-on installed, but still super notable).

      Currently we can do this kind of thing only when a Mozilla employee happens to be sharing a one-off graph from the AMO fire-hose, in the context of some unrelated blog story of theirs, that happens to disclose the data you need to answer your question, and that situation kind of sucks.

      (Compared to all other browser add-on hosting solutions, you still shine about enabling public high-res data about the eco system at all. Thanks for all your efforts so far!)

  5. Brian King wrote on

    Can we get locale information with the metadata ping? It would be very useful for both authors and localisers to know what add-ons are installed in what language versions of Firefox.

  6. microsoft certificering wrote on

    Could you explain what kind of problems spinning the event loop while waiting could cause in the case of ‘getExtensions’? Doesn’t the asynchronous version spin the event loop anyway? (The only difference I can see is that the syntax is more explicit.)

  7. Ángel wrote on

    This approach is flawed:
    * The privacy police (or just a note about this change) is not shown on update.
    * A hidden preference is not the appropiate way to store the switch which avoids an app phoning home.
    * The name of the key (extensions.getAddons.cache.enabled) is not appropiate. This is not about *caching* the addons (eg. metadata when the user manually browsed AMO), but *sending* data about the user preferences. Something like extensions.getAddons.reportExtensions would at least give an idea of what it did.

  8. Ping from Add-on Compatibility Progress & Plans « fligtar's blog on

    […] Firefox 4, as a result of enriched metadata in the Add-ons Manager, we have a much better idea of what add-ons are out there in the wild. And […]