Indistinguishable from Jesse

Testers can now download debug builds of Firefox rather than going trough the complicated process of building Firefox themselves.

Debug builds have extra code called assertions to inform us when assumptions or surrounding code are incorrect. For example, assertions can reliably tell us when third-party code makes common threading mistakes, even though the crashes from those mistakes appear random. I find about a third of my bugs by noticing assertion failures, and it usually isn't the assertion that's incorrect.

In several bug reports from users who were hitting frequent crashes at random, I suggested that the users compile their own debug builds, hoping that assertion failure messages would lead us to the cause of the crash. Few of the users succeeded, since the compilation tools and instructions were written with programmers in mind. Now that pre-made debug builds are available, we may be able to make more progress on these kinds of crash bug reports.

Big thanks to the release engineering team for making these builds available!

Reed Loden set up bugzil.la as a redirect for Bugzilla bugs and searches. Examples:

• http://bugzil.la/95849
• http://bugzil.la/468562#c12
• http://bugzil.la/firebug+crash
• http://bugzil.la/ALL+flag:in-litmus?

I put together a demo of incrementing numbers in URLs by scrolling.

Hopefully it's not considered a bug that I can use rangeOffset for a text node "inside" a textbox ;) Trying to access rangeParent throws a security exception.

This could be used by an extension like URL Flipper as a shortcut for changing specific numbers in URLs.

Getting Things Done recommends spending an hour or two on a "weekly review" every Friday afternoon. This worked for me at first, but after a month, I found myself procrastinating more often than actually doing a weekly review. Ironically, another concept from the same book helped me understand some of the reasons.

A major problem with my old weekly review checklist was that it included things I had to do in different contexts. For example, I can only check snail mail at home, but I can only check voice mail when I'm not at home. Worse, performing a weekly review seemed to require concentrating on one thing for an hour, and I'd rather spend that concentration on programming.

I decided to split my weekly review into a list of weekly sanity reminders, with each reminder on appropriate day of the week. I chose Monday for reviewing actions assigned to specific contexts, since the contexts "office" and "business-hours" usually become available on Monday. But I review coding projects later in the week, when distractions have died down.

For many of the smaller parts of my old weekly review, such as making sure my iPhone's voicemail list is empty, I chose a day of the week on which a mid-day meeting breaks up my day.

Splitting my weekly review into multiple scheduled items allowed me to put some reminders on the days when they do the most good, and others on the days when distractions do the least harm.

Like the author of GTD, I found that doing each of these things once a week helps me focus on the right projects and avoid some forms of procrastination. They just don't all need to be done on the same day.

Yesterday, I subscribed to the hg feed for reftest.js in Google Reader. Today, Google Reader informed me of a change Mats made. It works!

My newest Greasemonkey script, Buglist in input order, lets you sort a bug list according to an order external to Bugzilla.

For example, you can view the list of bugs related to topcrashes sorted by how common each crash is. First, load the list of Firefox 3.5.3 topcrashes. Second, use the "collect buglinks" bookmarklet to view a bug list consisting of the bug numbers listed there. Third, click the "#" added by this Greasemonkey script to sort the bugs by their order on the topcrash page.

Hopefully, this script will allow us to avoid duplicating information between Bugzilla and CrashKill wiki pages, and thus reduce the risk of information in both places becoming out of date.

Today is the second crash bug triage day. Can we beat the first one's record of resolving 104 crash bugs and identifying several important, valid bugs?

(Short, time-specific blog posts feel weird now. You should follow me on Twitter.)

User experience designers Alex Faaborg and Alexander Limi are looking to broaden the scope of efforts to make Firefox faster. Until recently, most of the effort has involved reducing the computation time needed to launch Firefox or render a web page. Faaborg and Limi argue that we should also look for ways to make computation time matter less.

The wiki page Perceived Performance contains a long list of ideas. Don't be fooled by the "perceived" part of the name: although a few of the ideas would merely make Firefox users happier, most of the ideas are aimed at reducing the amount of time users spend waiting for Firefox to do various things.

Common themes include:

Improve handling and feel during input. For example, letting scrolling "accelerate" makes rapid scrolling easier without harming the ability to make fine adjustments.

Give instant feedback in response to input, even if an operation has to continue in the background. In addition to reducing human waiting time, these fixes make the experience feel more like direct manipulation and less like telling Firefox what to do. (See also: "snappiness" bugs.)

Allow users to interact with partially loaded pages sooner. This is especially important with slow connections, which are becoming common again as computing goes mobile. Boris Zbarsky's interruptible reflow work is likely to help, and I added some ideas about making better use of the cache.

Reduce the number of clicks and keypresses needed for the most common interactions.

Give users new tools that let them avoid waiting. The introduction of tabbed browsing made it matter less when pages loaded slowly, by letting users load links in background tabs while continuing to read, but also introduced new problems.

Diminish frustration when slowness can't be helped by making changes to activity indicators, progress bars, and other messages. Give users the impression that Firefox is working hard, and help users make better choices about whether to wait.

What kinds of slowness do you encounter while using Firefox? Where should we focus performance efforts, whether by reducing computation time or through more clever means? Can you think of new ways to apply the themes above, or any other ways to make Firefox faster where it matters?