It’s been a while since I’ve done much reporting of bugs, at least not like I used to do. In my “early” years with the project, I reported all sorts of issues I found in normal usage. Later, during the march to 1.0 and the kickoff of 1.5, I filed series after series of bugs as we implemented new features and as Sam, Ian, and I retriaged years worth of existing bugs. Since then, however, I’ve spent more time triaging just-filed bugs, driving releases, and occasionally even fixing bugs. My last real spurt of bug reports came with the Cocoa native theme rewrite, which was over a year ago.
Recently, though, it feels like I’m back in bug-reporting mode, finding three bugs to report while testing a fix for one other bug. The recent Bugzilla upgrade had a few rough edges, and for whatever reason I seemed to find a number of them first. In addition to that, we recently landed some new security UI in Camino, so I’ve been poking around in some obscure areas of our interface.
The story of Camino’s security UI is a bit of a sad one; much of it is not user-facing at all (i.e., it’s not the lock icon or the location bar), and most of it is a 20% feature—one of those parts of the program that at most 20% of users need. The problem with this little bit of 20% UI is that it’s not something that can be lived without, or worked around, or implemented by an add-on, if you do need it, and as the web tends to be a mess, chances are better than usual that everyone will need to use it once. Simon probably put it best when he wrote about implementing this UI (in 2005; his post dates were all reset at some point).
In the past three years, we’ve largely left that UI in the state Simon committed it. No one paid much attention to the UI, since few people ever interacted with it. Occasionally someone filed a bug about a bit of UI polish (often one of our localizers, who had more interaction with those windows and sheets than 90% of our users), but the UI you see today in Camino is still almost entirely the bits in that initial commit. However, since the Gecko 1.9 security UI model changes forced us to rewrite some of those windows and sheets, I’ve been spending some time working through them, noting all of the bits of polish and bug-removal that the security UI missed out on when we upgraded the rest of Camino. (When Håkan started working on accessibility, he cleaned up a lot of our broken keyboard loops; similarly, Ian made a pass through all of the preference panes before Camino 1.5 to harmonize their layout and appearance.) All that poking in dark corners, in turn, led to a spurt of bug-filing on my part. It feels like old times again (well, without the late nights in Bugzilla and the constant laughs with Sam and Ian)….
In related bug-reporting news, Panic’s Steven Frank wrote an excellent guide to reporting bugs in Mac applications. There are two small qualifications that I would make: first, check the application’s bug database guidelines or “reporting a bug” web page (if any) before submitting a bug report. Some bug databases or trackers—usually systems that are completely open and public—may recommend searching existing reports before filing a bug to avoid submitting a duplicate report (not all developers have the time to spare to process duplicates). The guidelines for some trackers may even define another way to indicate you’re experiencing said bug. For instance, in Camino’s bug tracker, bugzilla.mozilla.org, filing duplicate bug reports is discouraged, and voting is the preferred mechanism for indicating that the bug affects you, too, and you want to see it fixed.
Second, make sure the developer is set up to receive that video file you’ve made of yourself reproducing the bug. Don’t attach the video to your initial email to the developer’s support address; instead, post the video on your own website or use YouTube—that’s got to be a better use of Google’s bandwidth than stupid pet tricks.
All in all, it’s a superb guide, and I encourage you to read it before reporting your next bug. Remember, good bug reports are good for everyone!