shaver

One aspect of our product performance that I’m especially interested in knowing more about is responsiveness: when the user does something, how long does it take for us to act on that stimulus? (We might not complete it instantly, as when loading a new page, but we should endeavour to give feedback pretty much instantly.) One thing that sometimes interferes with our interface responsiveness is spending too long away from the main event loop, perhaps in layout or some other intensive computation. This leads to us not noticing — and thus, obviously, acting on — new events from the user such as mouse clicks or keypresses.

I’ve been talking for a while about wanting to measure our UI-thread event service latency as a proxy for that kind of responsiveness, and so this morning I finally just sat down and did it while I was waiting for Tyla to get out of bed. The patch (link fixed now, sorry) is pretty small, though it’s also rough: no control of buffer size or minimum reporting latency without recompiling, that sort of thing.

I plugged the samples from a short run into Numbers — which then beachballed a little while generating the graph, naturally — and this is the result:

The taller portion at the right is from me going to an SVG statistics widget and dragging the sample-picker around like a bandit. On my laptop, we got a little above the 200 ms rule-of-thumb perception threshold for interactivity, and indeed I did start to notice that it was lagging a little behind my motion. I had other tabs open and stuff going on on my computer, etc., so it’s not Very Good Science, but it does give me hope that something like this monitoring will prove a decent proxy for one aspect of responsiveness. (Note that I just drop all samples that are less than 10 milliseconds, so these result sets will tend to give a negative impression of the application, by focusing only on events that actually take meaningful time to process.)

Mark blogged about the new Firefox -app switch, which I think is a pretty interesting thing. Of course, it’s not a substitute for XULRunner, which gives the application developer complete control over important things like the update cycle and process, and it’s definitely not something that we’re recommending people use without a lot of careful study.

This is something that we’ve been asked to provide for quite some time, and even with the tight coupling to Firefox in versioning and launch syntax I think it’s going to be a valuable addition to the repertoire. Here’s how I now see the platform spectrum for our technology:

• Web applications. If you can do it here, you should. We’re working with other browser developers to develop and standardize new web-platform capabilities all the time, because being able to put your app in this bucket brings a ridiculously large number of benefits for users and developers both. With webrunner you’ll have a way to give users an optional desktop-launch experience that they may be more comfortable with, even.

• Firefox extensions. There are thousands of them that have been able to build great experiences (and, in some cases, great businesses) with products that are tied to the Firefox maintenance-update rhythm, and we’re seeing more great stuff all the time.

• Firefox “-app” apps. This is a nice little hybrid where you are still coupled to the Firefox update cycle and so forth, but get more isolation from the browser process and end-to-end control over the UI. As Mr. Finkle said, this is a sharp tool with its handle loosely attached, so please use care when using it. If extensions aren’t suitable for your project because of the update cycle model, then this very much won’t be either. For prototyping, or some extension-like uses, it’ll be killer, though. (I like that the apps are started with “firefox -app”, because it’s another hint that the thing you’re doing is dependent on Firefox, and that changes to Firefox could hurt it. I think it would be more confusing to have it be called “apprunner”, f.e.)

• XULRunner apps. I need say little more on this topic; Joost and Songbird and Komodo and Miro and…yeah.

By no means do we expect, recommend or condone XULRunner-grade apps being moved to this model without extreme care, but a lot of people building such apps, especially smaller ones, have been asking for a way to piggyback off Firefox’s awesome update story while still having their own top-level chrome.

I’ll write more about this later, but since people are starting to pick this up, I want to get this out quickly.

When I wrote “ten fucking days” on a card for Robert (rsnake), I was intending to express my confidence in our ability to turn around a fix quickly if we needed to, by giving him a sort of “admit one” ticket for a disclosure that he thought needed an especially fast response due to extreme risk or some such. That was a bit overzealous, in the cold light of hindsight, but at no point did I intend to indicate that Mozilla policy was a ten-day turn around on all disclosed vulnerabilities. People are reading the conversation and Robert’s post that way, but that’s not our situation, and it certainly wasn’t my intent to give that impression.

I apologize, and hope that nobody will think less of Mozilla because of my error. We don’t issue challenges, and nobody here thinks that security response is a game. This was a personal bargain and overwrought showmanship from a late-night Black Hat party that has now taken on a life of its own, and I hope the fracas about my overzealous comments to Robert don’t overshadow the great work that people on the Mozilla project do to keep our users secure.

[Update: Window has posted on this topic as well, over at the Mozilla security blog.]