I already mentioned platform bugs in the previous article but this discussion is worth expanding. Fact is, with the XULRunner code base being rather huge you are bound to find bugs and inconsistencies if you only dig a little deeper. Most of them will be minor though some occasionally turn out mission critical.
Why report bugs?
Most bugs are will be easy to work around, like using collapsed instead of hidden or running an action asynchronously via setTimeout or something similarly trivial. But even if you found such a workaround and are going to use it — I recommend that you search existing bug reports and file a new bug if necessary. Why it is worth your time:
- The sad truth is, filing good bugs requires some skill. If you skip on the easy bugs you will have to learn things when you get a bug that you cannot skip — but that’s usually the bug where you would like to see results soon rather than waste time on trivial mistakes.
- Workarounds make code really ugly, I doubt that you want to keep them forever. However, if you don’t file a bug it could be that nobody else will either — and the issue won’t be fixed.
- Even if the issue will be fixed, there is no way for you to know. Eventually somebody (probably even you) will come and wonder why things were implemented in such a strange way. But without a bug number it is very hard to decide when the workaround can be removed.
- Gathering the information for a good bug report allows you to understand the issue better. Very often it allows finding a simpler workaround, sometimes it even makes filing the bug unnecessary by uncovering the logic flaw in the application which was mistaken for a platform bug.
- You are simply doing A Good Thing ™ by improving the platform and making sure other people don’t have to deal with the same bugs.
How to report?
I don’t want to go into basics of bug reporting here, it should be clear to anybody reading this article that allowing Mozilla developers to reproduce your issue is essential. So you should leave detailed steps to reproduce and all the relevant information of your configuration (especially: operating system, branch, build number – the kind of information that is listed in the Firefox User Agent string). Ideally you should do that with your first post, any kind of back-and-forth to gather relevant information easily delays progress on bugs by months.
But that’s not enough. More than a hundred bugs are filed in Bugzilla daily, Mozilla developers are too few to process all of them — and need to prioritize. The bugs that are more likely to get attention are usually the ones that are clearly described and easy to reproduce. This means in particular that a bug starting with the words “To reproduce install FooBar 1.2, create a new user account, change preference foo.bar” is rather unlikely to be looked at — even if some developer decides to install your application and go through all the steps he will simply get lost in tons of unfamiliar code. You should try to provide a minimal test case, ideally a simple HTML page or XUL document that can be attached to the bug report and opened from there directly. If your test case requires chrome privileges you can package it up as a tiny Firefox extension. Yes, test cases take time to produce but this is usually time well-spent as I explained above.
You get bonus points for showing how the bug affects Firefox or popular Firefox extensions rather than only your application. And there will be even more bonus points if you can attach a patch (use hg export to create patches because only these patches can be easily applied to the Mercurial repository). If you do, don’t forget to request review, otherwise nobody will notice. The review process can be lengthy and frustrating but once you got though all the hurdles it is only a tiny step and the bug is fixed.
The bug is fixed. Now what?
Of course it won’t help you immediately when the bug is fixed. Patches will mostly be applied to trunk only, XULRunner-based application usually live on stable branches however. You will have to wait for the next major XULRunner release before you can use the fix. At this point you have two options: either keep using a workaround or apply the patch to the XULRunner copy distributed with your application. In my experience, the former is always preferable if somehow applicable.
The problem with local patches (and especially ones that didn’t go into a XULRunner release) is that they make the already complicated process of updating to a newer XULRunner version significantly more time intensive. So far, the range in my experience was five patches (TomTom HOME, strict policy to keep only the absolutely necessary XULRunner patches) to something like eighty patches (Songbird). Updating the latter to a new XULRunner version was significantly harder, even the process of deciding which patches need to be kept took a week.
Comments