A Web Developer’s Responsibility

It’s safe to say that the biggest tax on a web developer is spending so much time dealing with browser bugs and incompatibilities. Thus it has become the favorite past-time of all web developers to complain about having to deal with them. Browser bugs are annoying, frustrating, and make your job incredibly difficult.

Because browser bugs are so frustrating and such a burden on top of normal development it should be the responsibility of every web developer to make sure that the browsers they develop for are able to find and fix their bugs. By taking responsibility for the bugs that you find – and to not assume that “someone else will find it” – will accelerate the rate at which browsers can improve.

The solution to helping browsers is two-fold: 1) Every time you find a browser bug, file a bug report to the respective browser. 2) Actively test your sites in the latest builds of the major browsers.

The vast majority of web developers have never filed a bug report with a browser vendor – or even used a nightly version of a browser – which is a shame. If you think about it there are few who are more qualified to assess what is going wrong in a browser than those who spend every day developing for them.

I’m especially surprised when I see professional developers not filing bugs with browsers, or testing on nightlies. Since one of the primary tasks of most developers is to paper over cross-browser issues it becomes in their best interest to see the number of bugs reduced (and making their job dramatically simpler).

I’ve personally filed bug reports with every major browser vendor and I’ve noted a couple characteristics that make for a good report.

How to File a Good Bug Report

The three points that make for a good bug report are: categorization, test case, and reduction. Any bug that is categorized correctly and provides a reduced test case is guaranteed to be reviewed by a browser developer.

Let’s start with where to file the bug itself.

Filing a Bug Report

Frequently when you go to file a bug report you have to wade a couple layers deep before you can get to the actual submission form. I’ve provided direct URLs to the best forms to use, below.

When you’re filing your bug be sure to also test it in the latest nightly of the browser you’re filing against (which I’ll describe later on). This will be one of the first things that a browser developer asks. If you can show that the bug still exists in the current development version of the browser, that it has not been fixed, then it’ll be that much easier for them to get started.

Note: Many of the bug report pages require that you create an account before submitting a report. This is an annoying one-time cost.

Categorizing the Bug

Categorizing a bug properly is an important first step. Frequently the owners of particular modules (such as layout or DOM) watch all new submissions that come in. Assigning a bug to the correct category will instantly put it before the eyes of the very person most capable of fixing the bug.

The categorization of a bug depends on the browser (some browsers, like Opera and Internet Explorer), provide simplified categories for filing a bug while others (WebKit/Safari and Mozilla/Firefox) use complex categories to denote the specific module where a piece of functionality might exist.

Mozilla/Firefox: Choose a Component. Some of the most common ones: DOM, Layout, JavaScript Engine.

WebKit/Safari: Choose a Component. Some of the most common ones: HTML DOM, Layout and Rendering, JavaScriptCore.

Google Chrome: Figuring out if you should file for Chrome is tricky. First test your bug in both the latest release of Safari and in the latest WebKit nightly. If the bug exists only in Chrome then file there, otherwise file the bug with WebKit/Safari. One problem, though: Bugs that only exist with the Chrome JavaScript engine (V8) should be filed in the V8 bug tracker instead of the Chrome one (lest it get lost in the shuffle).

Also, Chrome does not provide an explicit means of categorization. All bugs are reviewed by a developer and then categorized (you have no control over this process).

You should also take the quick step of testing on more than one platform (OS X and Windows, Windows and Linux, etc.). Simply determining that the bug exists on more than one platform can dramatically help to reduce the time needed to locate the cause of the bug by the browser developer.

Providing a Test Case

Any type of reproducible test case is better than nothing. A web page that’s able to encapsulate the problem is generally a good start. If the web page is able to be attached to the bug report directly, that’s even better (it may take a while for the browser developer to get around to your ticket and if your test case no longer exists at the URL that you specified then they’ll likely just close your ticket and move on).

That being said there is such a thing as a bad test case. The worst kind is something like: “I have a web site at http://example.com and it doesn’t work in browser X, please fix.” That will take someone a considerable amount of time to locate the exact reasons for failure and will likely push your bug much farther back on the queue.

The best kind of test case is one that provides a reduction.

Providing a Reduction

Providing a simple test case is absolutely the hardest and most frustrating part of creating a bug report – but it’s also the point that’ll make your report most likely to be noticed and fixed. Even for the most qualified developers it should take no more than 30 minutes to create a good-enough test case.

The process for creating one is simple: Take a page that has the bug in it and rip out anything that doesn’t affect the reproduction of the bug. This includes stylesheets, images, JavaScript files, JavaScript libraries, and HTML.

For example, a while back when I was running the Dromaeo test suite and I noticed that WebKit kept crashing when it hit a certain point. I began by ripping out tests, unnecessary HTML, CSS, and images. I eventually worked my way down to a single test: Splitting a string. I then worked to strip out as much of the test suite as possible so that there were no external dependencies required.

Note the final result:

var str = “”, ret, fn = [];

for ( var i = 0; i < 16384; i++ ) str += "a"; for ( var i = 16384; i <= 131072; i *= 2 ) (function(i){ fn.push(function(){ ret = str.split(""); }); str += str; })(); window.onload = function(){ setInterval(function(){ if ( fn.length ) fn.shift()(); }, 13); };[/js] What was left was about as simple as you could get while still having the crash occur. This is a good reduction. Based upon this reduction the reason for the problem was quickly identified and resolved just a couple weeks later.

Is my bug being worked on?

This is a challenging point – but one that’s easier to determine with Mozilla/Firefox, WebKit/Safari, and Chrome (since they’re all relatively open projects). Here’s the best way to determine the status of the bug with each of those browsers.

Mozilla/Firefox: Your bug will start out being assigned to the default contact for the component category that you originally selected. This doesn’t mean anything, yet, it’s simply attracting people in to look at your ticket. People will start to CC themselves in to the ticket (which means that they’re interested in its progress). The defining moment, though, is when someone assigns the bug to themselves, effectively stating that they are taking responsibility for the status of this bug. Most contributors have it set up so that any future comments on the bug are automatically emailed to them so if you have any questions about the status of the bug you can feel free to post a comment – but please do so at a reasonable pace (asking for daily, or even weekly, updates would be frustrating).

WebKit/Safari: WebKit uses a very similar setup to Mozilla/Firefox – just look for someone to take control of the bug and drive it to completion. The golden ticket, though, is when your bug “goes to rdar“. Radar is Apple’s internal (private) bug tracker. Having your bug move to there means that your bug is, effectively, guaranteed to be completed at some point (if not by the person who ‘owns’ it then by another Apple employee). Since Apple is still the major driving force behind WebKit updates having your bug move to rdar is what you should be hoping for. That being said, since rdar is private to Apple employees you no longer get the benefit of knowing if or when your bug will be completely fixed – it’s just a waiting game.

Chrome: Chrome uses a system very similar to Mozilla/Firefox. Be sure to keep up communication with whom the bug is currently assigned to and to answer any questions that they might have.

If your bug eventually gets resolved then congratulations! You just helped to make the web a better place for everyone.

But that’s not always the case.

What happens if my bug gets rejected?

Rejected bugs fall into two categories:

  1. It was rejected because it was not a bug.
  2. It was rejected because they browser vendor does not feel like working on it.

The first point is broken down into two further sub-categories:

It’s legitimately not a bug. Congratulations! You’ve learned something about a standard, or some other browser obscurity, that you weren’t familiar with: you’re now a better web developer! You should fire up your blog and write about the obscure new bug or API that you discovered and explain it to the world.

Or it is a bug and the owner unnecessarily closed it. At this point you need to argue your case to re-open it.

The second point (the vendor does not feel like working on it) is also handled in two ways:

First, argue your case for the bug. This should help inform the browser developer that they should dedicate valuable resources to fixing this issue.

Or second, if they are truly unwilling to fix the bug: Raise holy hell on your blog, Twitter account, and any other place where other web developers will listen to you. If you can’t find anyone else who agrees with your plight then you are probably crazy – but if it’s a legitimate problem that the browser vendor is refusing to fix then you should easily find others with whom you can band together and complain openly to. But that’s OK: You’ve earned this right. By doing all the due diligence necessary to bring this bug to light you earn full privileges of bitching about it in every other sentence.

Arguing a Bug

So you’re at the point where your bug has been closed and you need to convince the closer that this was a mistake – that what you have is an actual, legitimate, bug.

Here are some of the best arguments that you can use, in order of which they should be used:

  1. Show that the bug was a regression. Prove that it was something that worked in a previous release that stopped working because of a change. Works great in conjunction with #2.
  2. Show real-world web sites breaking. If you can show that actual users are going to no longer visit X bank in Poland or Y shopping site in Canada then browsers will easily bend over backwards to fix the issue (unless it’s Opera, in which case they may use their browser.js to force a site to work – but that’s another story).
  3. Show a web standard that is being violated by not fixing this bug. If you’re able to show that the W3C DOM specification is not implemented correctly because a certain bug is not fixed then a browser vendor should feel compelled to fix it. If not, this will make for great blog fodder.
  4. Show that not fixing the bug makes a browser incompatible with other browsers. If IE, Safari, and Opera all implement a specific feature or fix a specific bug then Firefox should be compelled to comply with the other implementations (as long as its not in contradiction with a specification). This is the hardest one to argue – but it becomes easier the more browsers that are on board.

If you can’t prove any of those steps then you’re probably just scratching your own itch anyway – and should lay off.

Examples

I want to show some representative examples of bugs that I’ve filed with different browser vendors.

WebKit/Safari

Canvas arc() with radius of 0 throws exception: Calling the Canvas arc() method was throwing an exception. I provided a super-simple test case and pointed to the specification that they were in disagreement with. Was resolved the same day it was posted.

Out of Memory Error with .split(“”) due to large number of live objects: Provided a simple reduction with hosted web page, was fixed about 3 weeks later.

Mozilla/Firefox

Huge Speed Drop in Array.prototype.sort: Showed a regression with a simple reduction. Included a bunch of very-useful Shark profiling data to help pinpoint the exact issue. Was fixed within a month.

Implement .children: Argued that Mozilla needed to implement the .children method (which was in every other major browser). A good debate led to its eventual inclusion (about 6 months later).

Internet Explorer 8

querySelectorAll NodeList Exception: Provided simple test case, was rejected due to ‘lack of time’:

At this time we do not plan on fixing this issue. We appreciate the report, but unfortunately we are at a stage where need to choose what we work on to maximize the value for customers and web developers.

So while they agree that it is an issue – they do not plan on fixing it. That means that I now get to complain about it!

HTMLElement.prototype.querySelectorAll doesn’t exist: As it turns out this was because querySelectorAll only exists in standards-compliant pages (not in quirksmode). This is positively bizarre but I think I understand their rationale behind the decision. I suspect that this will bite a lot of people once IE 8 goes live, we’ll see. I now know more about IE8 and am a better developer for it.

Google Chrome

for in loops don’t occur in defined order: This was a compatibility issue (all other browsers behaved in a particular manner). I provided a simple test case. It was accidentally closed as WontFix (which caused confusion) but was actually fixed. I made a mistake here and actually filed this bug against Chrome when it should’ve been against V8 – here’s the bug that dealt with the issue over there.

setTimeout(…, 0) fires too quickly: This was actually due to a structural change made by the Chrome team. Mike Belshe (the author of the change) personally emailed me to explain what happened. I became much more informed as a result and blogged about it.

Opera

(Opera does not provide an official public view for bug reports, that I know of.)

How to Test a Nightly Build

Before we get into the details of testing a nightly build of a browser I should probably answer the most common question: Why should I care about testing a nightly build of a browser? There are a couple reasons.

First, when filing a bug report you’re going to need to determine if the bug you’re submitting has already been fixed, or not. If it’s already been fixed in a nightly then you don’t need to worry about submitting it – the bug will be fixed in the next release. If the bug has not been resolved, though, then you should be sure to continue filing the bug.

Second, you should periodically test your site or library in the latest browser nightlies – to make sure that your code isn’t going to break when the browser is released. How often you test is up to you – but the more frequently you test the more likely it is that your site or library won’t hit a massive regression at some point. I think it’s pretty safe to say that no developer likes finding out that there’s a new browser version on the market that breaks their site.

Filing a bug for a nightly is just like filing any other bug. Provide a reduced test case and be sure to emphasize that a regression occurred. If you’re testing frequently enough this should be sure to get the developers hopping into action.

Getting the Latest Nightly

Browser vendors provide a variety of techniques for getting the latest version of a browser. Some browsers release more frequently than others, as well (for example, Chrome updates multiple times a day, Firefox once a day, and Opera every couple weeks or so).

Mozilla/Firefox

Mozilla provides nightly releases of Firefox. It can be installed, and used, alongside your existing copy of Firefox using Firefox Profiles. Once you download one nightly release it should update itself, automatically, every day.

Download: Firefox Nightly Release

WebKit/Safari

WebKit nightlies are easy to install on OS X – they can live completely side-by-side with no profile details. However they do not update automatically. I use NightShift to make sure that my WebKit nightly is kept up to date (on OS X).

Doing a nightly install on Windows is much more cumbersome (it involves running some scripts and copying files around) but it works.

Download: WebKit/Safari Nightly Release

Internet Explorer

Internet Explorer installs are “a big deal” – they completely blow away any previously-installed copy of the browser. For this reason you should be sure to use some tricks to keep multiple copies of Internet Explorer installed on your system. There’s one installer that can handle IE 6 (and older) and another one for taking care of IE 7. Once you have all those standalone versions installed you can feel safe downloading and installing IE 8.

IE 8 automatically updated from each beta release but it doesn’t appear to do it any more. If you sign up for the Microsoft IE Beta Connect program you can get more recent builds to test against. Again, all of these builds will overwrite older versions of the current browser.

Download: IE 8 Betas, IE 8 Weekly Builds

Google Chrome

Google provides multiple builds per day (one for each revision). These builds can live side-by-side with one another but they do not update automatically. One user built an automatic update application that you can use to make that happen.

Download: Google Chrome Nightly Builds

Opera

Multiple versions of Opera can be installed side-by-side and they update automatically. They don’t provide nightly builds (they come out every couple weeks, or so) but they should serve as a relatively-current example of the browser.

Download: Opera Desktop Team Blog (builds are posted here)


The importance of taking an active role in the future of web development cannot be overstated. Shifting from a passive position of hoping that other developers will be proactive about filing bugs or hoping that browser vendors will notice every possible regression to one of active diligence gives you an incredible amount of power. The minimal amount of work that you do to improve communication between the web community and browsers does volumes for helping to improve the quality of the entire web.

You should wear every bug that has gotten fixed, because of you, as a badge of honor: You’ve done your part to make the web a better place.

Posted: December 29th, 2008


Subscribe for email updates

60 Comments (Show Comments)



Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.


Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.