Downloads API, sixth update

Gavin Sharp gavin at gavinsharp.com
Sat Sep 14 23:07:05 UTC 2013


Thanks for the update, Paolo - they're very useful.

How did you calculate the 6% figure, out of curiosity? I've been
meaning to do some jydoop number crunching on more specific queries
than what the dashboard gives us, maybe we can chat about this
further.

Gavin

On Wed, Sep 11, 2013 at 2:48 AM, Paolo Amadini
<paolo.02.prg at amadzone.org> wrote:
> The Downloads API has been enabled in Nightly for three weeks now,
> and we are already seeing a drastic improvement in responsiveness!
>
> Our Telemetry infrastructure is showing that the overall time spent on
> the "UPDATE moz_downloads" SQLite query, during which the browser
> interface is unresponsive because of main-thread I/O, has now been
> reduced *to* only 6% of the previous value!
>
> *Add-on compatibility*
>
> Since the new API is not using SQLite anymore, the above figure should
> tend to zero over time. The reason why we are not there yet, and we
> still see reports of SQLite queries, is probably that some installations
> had to switch to the old API for compatibilty with download-related
> add-ons. The preference to do that is still available in Nightly, but
> will soon be removed as planned, in favor of a build-time setting.
>
> Following up to our mozilla.dev.extensions post [1], we will actively
> reach out to all the developers of download-related add-ons registered
> on addons.mozilla.org, in advance of the Aurora migration of Firefox 26,
> with all the needed technical details and contact information.
>
> While the plan is still to complete the migration in Firefox 26, and
> remove the preference to disable the new API in Nightly, we think we can
> do a service to our users and add-on developers by retaining the ability
> to switch to the old API during the first part of the Aurora cycle.
>
> The idea is that, for about one more month on Aurora, it will be
> possible for end users to flip the temporary preference to continue
> using their add-ons until they are updated, and for add-on developers
> to do a comparison of functionality on the same Aurora profile. When
> Firefox 26 reaches Beta, the new API will be enabled permanently.
>
> *Feedback received*
>
> As expected, most of the feedback received during these weeks was
> related to known bugs tracking final release, like the fact that some
> downloads weren't added to history (fixed in bug 908240) and the
> reimplementation of the taskbar indicator (bug 906620). There is also
> one minor Downloads Panel bug that needs investigation (bug 910236).
>
> We also received positive feedback on a change made possible by the new
> design, the fact that failed downloads can be restarted from where they
> stopped (previously, it was possible only on downloads that were paused
> manually).
>
> The Metro Firefox team has also started looking into the new API, and is
> currently doing a preliminary evaluation with regard to switching to it
> in the short term. We are looking forward to having more details on
> their specific needs to update the back-end accordingly, though it
> looks like most, if not all, of the required features are already there.
>
> *Remaining work*
>
> Last week has seen tremendous progress, with 10 out of 12 bugs tracking
> release that are ready or have a patch posted for review. The two
> remaining bugs are the taskbar indicator front-end and the minor Panel
> issue, while the taskbar indicator back-end is up for review.
>
> *API changes*
>
> As part of adding new features, we are changing the method to retrieve
> the lists of downloads, and adding a combined list of public and private
> downloads (bug 913118). For example, "Downloads.getPublicDownloadList()"
> will be replaced by "Downloads.getList(Downloads.PUBLIC)".
>
> We'll have a general high-level API review later this week, likely on
> Friday, to identify any possible last-minute improvements before we
> migrate to Aurora. After that, the number of breaking changes will be
> reduced to the usual level for our more stable APIs, as needed.
>
> *Providing feedback*
>
> As usual, regressions should be filed as blocking bug 825588. Add-on
> compatibility bugs are tracked by bug 907764 instead, and should be
> filed under the "Firefox::Extension Compatibility" component [2].
>
> Cheers,
> Paolo
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.extensions/ltOB3MzVwcI/K8DwIKkkUR0J
> [2]
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Extension%20Compatibility&blocked=907764
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev



More information about the firefox-dev mailing list