What David Did During Q3

September 30, 2014 § 6 Comments

September is ending, and with it Q3 of 2014. It’s time for a brief report, so here is what happened during the summer.

Session Restore

After ~18 months working on Session Restore, I am progressively switching away from that topic. Most of the main performance issues that we set out to solve have been solved already, we have considerably improved safety, cleaned up lots of the code, and added plenty of measurements.

During this quarter, I have been working on various attempts to optimize both loading speed and saving speed. Unfortunately, both ongoing works were delayed by external factors and postponed to a yet undetermined date. I have also been hard at work on trying to pin down performance regressions (which turned out to be external to Session Restore) and safety bugs (which were eventually found and fixed by Tim Taubert).

In the next quarter, I plan to work on Session Restore only in a support role, for the purpose of reviewing and mentoring.

Also, a rant The work on Session Restore has relied heavily on collaboration between the Perf team and the FxTeam. Unfortunately, the resources were not always available to make this collaboration work. I imagine that the FxTeam is spread too thin onto too many tasks, with too many fires to fight. Regardless, the symptom I experienced is that during the course of this work, both low-priority, high-priority and safety-critical patches have been left to rot without reviews, despite my repeated requests, for 6, 8 or 10 weeks, much to the dismay of everyone involved. This means man·months of work thrown to /dev/null, along with quarterly objectives, morale, opportunities, contributors and good ideas.

I will try and blog about this, eventually. But please, in the future, everyone: remember that in the long run, the priority of getting reviews done (or explaining that you’re not going to) is a quite higher than the priority of writing code.

Async Tooling

Many improvements to Async Tooling landed during Q3. We now have the PromiseWorker, which simplifies considerably the work of interacting between the main thread and workers, for both Firefox and add-on developers. I hear that the first add-on to make use of this new feature is currently being developed. New features, bugfixes and optimizations landed for OS.File. We have also landed the ability to watch for changes in a directory (under Windows only, for the time being).

Sadly, my work on interactions between Promise and the Test Suite is currently blocked until the DevTools team manages to get all the uncaught asynchronous errors under control. It’s hard work, and I can understand that it is not a high priority for them, so in Q4, I will try to find a way to land my work and activate it only for a subset of the mochitest suites.


I have recently joined the newly restarted effort to improve the performance of Places, the subsystem that handles our bookmarks, history, etc. For the moment, I am still getting warmed up, but I expect that most of my work during Q4 will be related to Places.


Most of my effort during Q3 was spent improving the Shutdown of Firefox. Where we already had support for shutting down asynchronously JavaScript services/consumers, we now also have support for native services and consumers. Also, I am in the process of landing Telemetry that will let us find out the duration of the various stages of shutdown, an information that we could not access until now.

As it turns out, we had many crashes during asynchronous shutdown, a few of them safety-critical. At the time, we did not have the necessary tools to determine to prioritize our efforts or to find out whether our patches had effectively fixed bugs, so I built a dashboard to extract and display the relevant information on such crashes. This proved a wise investment, as we spent plenty of time fighting AsyncShutdown-related fires using this dashboard.

In addition to the “clean shutdown” mechanism provided by AsyncShutdown, we also now have the Shutdown Terminator. This is a watchdog subsystem, launched during shutdown, and it ensures that, no matter what, Firefox always eventually shuts down. I am waiting for data from our Crash Scene Investigators to tell us how often we need this watchdog in practice.


I lost track of how many code contributors I interacted with during the quarter, but that represents hundreds of e-mails, as well as countless hours on IRC and Bugzilla, and a few hours on ask.mozilla.org. This year’s mozEdu teaching is also looking good.

We also launched FirefoxOS in France, with big success. I found myself in a supermarket, presenting the ZTE Open C and the activities of Mozilla to the crowds, and this was a pleasing experience.

For Q4, expect more mozEdu, more mentoring, and more sleepless hours helping contributors debug their patches🙂

§ 6 Responses to What David Did During Q3

  • Harsh86 says:


    Mozillians everywhere appreciate any and all efforts made to improve the general performance & responsiveness of Firefox. For a lot of us its often a major drain on our patience, but finally it looks choosing the right browser isn’t going to be a compromise in the way of a good butter smooth experience.

    Your and your teams efforts, David, haven’t gone unnoticed. Please do keep it up and hang in there. We do appreciate it. This goes to all teams involved in this effort and your predecessors.

    Thanks again.

  • Gavin Sharp says:

    “Patches left to rot for weeks” is absolutely unacceptable. Please never let it get anywhere near that point without raising an objection to the module owner in question (or even further, if needed). In this case that was me, and I would not have let that stand. (I shouldn’t be relying on self-reporting for this – I am looking to improve that as well, stay tuned to firefox-dev.)

    For sessionstore specifically, I recall several conversations between Tim/you/I discussing and disagreeing about the relative priority of some of the work you were doing there, and that manifested itself as lack of review attention. That this feedback was not reflected with Bugzilla review flags is definitely also a problem, but I think a less severe one than “review requests ignored”.

    I’d love to chat more about specific examples if you’re willing.

    • yoric says:

      This doesn’t feel right. We are adults. A reviewer should at least be able to reply himself that he is not going to review, without me having to escalate the issue. This, by itself, is simply not acceptable.

      There are both attenuating and extenuating circumstances for the specific examples, but I would rather avoid discussing them in public. Let’s chat about them some day.

      • gavinsharp says:

        I am not suggesting that the base expectation is that you, as a review requester, need to escalate every review request. I’m suggesting that when the system fails, as it did here, you have recourse other than writing a blog post about it weeks later. I agree with you that this should ideally never be necessary – my job is to be pro-active in addressing the problem of slow reviews, not just reactive. As mentioned I will followup about how I plan to address that on firefox-dev soon.

      • yoric says:

        This blog post is a Q3 report, not a recourse. I have given up on that task because I am blocked by external factors, and I explain why.

        I am (was) planning to write a further blog post to share my guidelines on how and when to review, but if you are planning to followup and address the issue, I can wait a bit.

      • gavinsharp says:

        You don’t need to wait for me to blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading What David Did During Q3 at Il y a du thé renversé au bord de la table.


%d bloggers like this: