Archive for the 'Mozilla' Category

Opening video

Monday, June 29th, 2009

Looks like Firefox 3.5's support for open video has already inspired:

And Firefox 3.5 hasn't even been released yet. This Open Video thing might just work.

Need help reproducing a JIT crash

Tuesday, June 23rd, 2009

The top crash signature for Firefox 3.5 Beta 99 and last Friday's Firefox 3.5 Release Candidate is "js_MonitorLoopEdge". This signature indicates a crash within code generated by the TraceMonkey JIT compiler. Bug 499169 tracks this topcrash.

The scariest part is that we don't know whether the large number of crashes is due to a single bug or multiple bugs. (All crashes in JIT code appear with the same signature because the crash reporter does not understand the structure of the generated code.) We might not even know until we fix one bug and ship a new release candidate to a large number of users.

We have a list of 3000 URLs associated with js_MonitorLoopEdge crash reports. Bob Clary is going to try loading all 3000 pages. Damon Sicore has already identified one page that crashes reliably. While Andreas Gal debugs it, I'm going to try to make a reduced testcase.

These efforts should fix any crashes triggered by simply loading popular web pages, but might not catch other bugs that involve extensions or when interacting with web pages in a specific way.

If you've been hitting crashes in js_MonitorLoopEdge, please try to figure out how to reproduce them and share what information you can. Click the links in about:crashes to find out if your crashes are in this function. The sooner we figure this out, the sooner we can ship a stable Firefox 3.5.

Of quests and bookmarks

Sunday, April 26th, 2009

I'd like to see more software nudge people in the direction of GTD's low-stress productivity.


World of Warcraft organizes your quests according to where you discovered them, not according to where you can make progress on them. You can easily have your character in the right town but forget to advance one of your quests.

Since the game's quest organization is so unwieldy, it limits players to 25 quests. This forces some players to abandon quests with the intent of picking them up again later. But more importantly, "only write down the most important stuff" is the wrong message to send to our children.

Having to maintain your own lists outside of the game makes playing the game too much like work. If instead, the game subtly taught players how to work effectively, they might have more time to play.


Thunderbird's default set of color labels reflects priorities and reasons (important, work, personal, to do, later). These labels don't really help move messages out of the inbox.

Instead, Thunderbird should suggest contexts and non-action sets (home, office, errands, waiting for reply, reference).


Firefox has the distinction of containing three dangerous stuff magnets: the bookmarks menu, the bookmarks toolbar, and session restore. I've seen several coworkers fall into the session restore trap, and it's not pretty: with hundreds of tabs, Firefox can take minutes to start.

I like Jono's suggestion of replacing bookmarks with features that speak more directly to use cases like to-read, sharing, and reference. Firefox 3's tags make reference possible but not much else.

To-read is the trickiest, since it can't really be organized. Separating to-read from sharing and reference is enough to keep those other categories clean, but to-read has to work if it's going to be used. Maybe Firefox can include hints about how to use to-read effectively, like having an "airplane" button you click to open all of them in tabs just before you disconnect from the tubes. Or maybe Firefox can keep those items ready for reading without the overhead of having them open in tabs all the time.


What other software could encourage people to discover contexts and the next-action principle? Where else can workflows be improved, so collection buckets are emptied naturally, and users don't need to make a special effort to "stay organized"?

Performance graphs

Thursday, April 23rd, 2009

Alice suggested that instead of asking for the graph links to be maintained, I could instead file bugs for making the graph server not suck so much that we need the graph links. I filed four bugs, but I'm not one of the main consumers of performance graphs, so it would be good for actual developers and sheriffs to weigh in.

What use cases are important and not covered well by the (new) graph server, johnath's performance dashboard, and the automated posts to What would help us notice and track down performance regressions quickly?

Getting bugs done

Monday, April 20th, 2009

I believe Bugzilla's workflow can be improved using one of the central ideas from Getting Things Done, the "next action".

Currently, the answer to the question "what is needed to move this bug forward?" is scattered throughout each bug report. Sometimes it's a keyword, sometimes it's a review flag, and sometimes it's the third-to-last comment. It takes me maybe a minute per bug to determine whether I can help, and this wasted time adds up quickly.

Next-actions for bugs

I propose replacing the status field with a next action field, and the assignee field with a next action assignee field. The "next action" field answers the question "what is needed to move this bug forward":

All bugs
  • Understand what's wrong with the code
  • Write patch
  • Automate test
  • Review patch
  • Approve patch
  • Push patch to mozilla-central
Major refactorings
  • Create tests for existing code
  • Design new code
  • Review design
  • Test patch on try server
  • Test patch against fuzzers
  • Fix whatever caused the back-out
New features
  • Provide ideas
  • Experiment by writing extensions
  • Experiment in a usability lab
  • Consider security ramifications
  • Consider accessibility concerns
  • Decide whether it goes in
  • Specify desired behavior in detail
Layout bugs
  • Reduce testcase
  • Find regression range
  • Check against CSS spec
  • Get crash stack
  • Get hang profile
  • Run under valgrind
  • Debug with gdb

Organizing actions by context lets me remember projects when I can move them forward, rather than when they only increase my anxiety. This may be even more important in a community system: who you are is a key context determining whether you can do something.

With a next-action field, it would be easier to find places to put my skills to good use:

  • Did Brendan hope to have this patch fuzzed?
  • What bugs are waiting for input from the security team?
  • What bugs could benefit from extension-space experimentation?

With the addition of a next-action-assignee field, I'd also be able to do searches like:

  • What have I been asked to do in Bugzilla?
  • What blockers are stuck on me?
  • What bugs need someone to volunteer to make a reduced testcase?

Simplifying Bugzilla

I'm asking for new fields, but I think this will actually make Bugzilla less complicated. The "next action" field and its assignee would replace:

  • The current "status" field, which is mostly useless because each open state (unconfirmed / new / reopened / assigned) can mean so many different things.
  • The current "assignee" field, which is misleading when the next action required is anything other than "write a patch" or "check it in".
  • Eleven keywords: uiwanted, qawanted, helpwanted, stackwanted, icon, testtracker, crashreportid, regressionwindow-wanted, testcase-wanted, checkin-needed, push-needed.
  • Status whiteboard markers like "[needs review gavin]" and "DUPEME".
  • Many comments that are only temporarily meaningful.

It would also make our process more transparent: there is always a first-level answer to "Why hasn't this bug been fixed yet?"

How I use GTD

Thursday, April 16th, 2009

I started using Things in February when my coworker Jay Patel recommended it. I found it useful immediately, but my friend Alan Levin told me I had to read Getting Things Done to really understand how to use Things. He was right.

GTD is all about organizing actions so you notice them when they are possible. The book is full of great structures and tips for doing this, but I've taken advantage of the flexibility as much as the suggested structures.

My contexts

I use three sets of contexts to help me remember things where they are relevant.

  • Frequent contexts: "home", "office", "errands". I use these not only to remember things at the right time, but also to plan rounds of errands and decide whether to go into the office on Fridays.
  • Rare contexts: "Mozilla all-hands", "in Los Angeles".
  • Anti-contexts: "read", "listen". These items are best saved for when I am disconnected, e.g. on an airplane or in a hotel room.

These contexts account for most of my tags in Things. I also make heavy use of the "scheduled items" feature to get stuff out of my way until it becomes relevant.

Multi-part projects

"Do taxes" crossed multiple contexts, so I had to break it down into individual actions. For example, faxing the forms was tagged as "office", because that's where I have easy access to a fax machine.

One tricky thing to categorize was waiting for my tax forms to arrive in the mail. GTD recommends having a special "Waiting For" list and checking it weekly, but I find it more relaxing to decide up front how long I'm willing to wait. Then I schedule a conditional item: "If I haven't received the tax forms by today, ask for a faxed copy".

Energy and concentration

The hardest actions for me to organize are the ones I can do anywhere I have my laptop and Internet access. Unfortunately, they're also the most numerous.

I tag these with the length of concentration required to make progress. This can be hard to estimate, but it's more relevant than knowing how long something will take in total. Processing my inbox took very little concentration, so despite being a large undertaking, it was a good thing to tackle while waiting for a phone call or just before lunch. In contrast, designing and implementing a new software tool takes concentration; if I start just before a meeting, I'll have wasted most of that time.

Weekly review

To keep myself from worrying that I'll forget about something that turns out to be important, I try to take some time on Friday afternoon to reorient myself. My weekly review checklist is mostly the same as the one in the book, customized for my inputs. The only unusual item on my checklist reflects my coding ability and flexible work environment:

Am I doing anything inefficiently? Can I automate it, improve my workflow, or delegate it?


  • Using GTD has unleashed more creative energy than I thought I had in me. You can see some of this in my last few months of blog posts. I believe this is a common experience for people who start using GTD, but I don't understand why.
  • My anxiety seems to have decreased quite a bit, to the point where I might be able to get away with 5mg less Lexapro.
  • It's possible for me to keep my inbox empty, which makes checking for new email less of a distraction.
  • Processing all my stuff led me to discover five separate lists of movies I want to see. Now that I have a single list, it might finally make sense to sign up for Netflix.
  • Instead of being bored while I'm on a train or airplane, I'm reasonably productive.
  • If I get sick, I can stay home and still find meaningful work to do.
  • The GTD workflow is simpler than the procrastinator's workflow.


  • It feels impersonal to manage every part of my life in the same system.
  • I haven't figured out how to make priorities mesh with GTD. I can tag items as "saves me time" or "only useful if done soon", but I don't tend to look at those tags. Some people invent fake deadlines, but that seems dangerous.
  • I'm still not good at setting aside time for projects that require significant amounts of concentration. Perhaps I need to create a habit of setting aside one day a week for that kind of thing, and make sure I have all the little things out of the way before that day.
  • I now cringe every time I hear someone say "it's on my mental list".
  • I have gained a new enemy: tools that impose bad workflows.

The more things change

Friday, April 10th, 2009

1999: Linux needs a working Web browser.

2008: Linux needs a working Flash player.


Thursday, April 9th, 2009

Bug reports in can now be changed back to UNCONFIRMED. Sweet! I'll use this next time I accidentally file a bug that lacks a reduced testcase a "NEW".

(From one of the three long threads on about Bugzilla statuses and workflow.)