Downloads API, sixth update

Paolo Amadini paolo.02.prg at
Tue Sep 10 19:48:53 UTC 2013

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 post [1], we will actively
reach out to all the developers of download-related add-ons registered
on, 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

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].



More information about the firefox-dev mailing list