My younger self (the fool he was) believed that reporting browser issues would be in exercise in futility. My thinking was something like this: “Browser makers are these big monolithic ‘things’ and I’m just one man. They aren’t going to take any notice.”

I had been scarred by attempting to report bugs with the like of Adobe and Microsoft. Now that really is an exercise in futility! Have you ever tried reporting a problem to Adobe? I know, I know. Anyone there Adobe? Hellooooo? (cue tumbleweeds)

However, I remember some time ago reading Lea Verou’s excellent post on reporting browser bugs and promised myself that the next time I hit something appropriate I’d put the advice into practice.

I’m happy to report that having done so recently with three separate browser camps, doing so is definitely worth your time. Here is my brief anecdotal evidence to support this claim:


In my effort to be a better web citizen (OK, I admit it, I actually wanted something fixed for my own selfish needs) I wanted to report an anomaly I was experiencing in Firefox. Both Chrome and Safari were rendering as I expected but Firefox (and Opera) wasn’t playing ball. I had done my homework and created a reduced test case so I was fairly confident something odd was occurring.

First off I posted on Stack Overflow. When nothing was forthcoming I nervously posted on the Firefox Bugzilla system. Here’s the bug I filed:

In this instance, as it turns out, it wasn’t so much a problem in Firefox, more a disparity in the manner that other browsers interpreted the spec (the Mozilla team member opened bugs at WebKit and Chrome off the back of it) and how I understood things should work. Although nothing changed in Firefox as a result, I at least came away with a consistent and robust way to achieve what I needed. The important thing to note dear reader is that the system worked. The mozilla people got to the bottom of the issue. A result for me, even though I felt more humbled than usual for my schoolboy error.


The second case was more interesting from my point of view as it demonstrated how quickly fixes can get rolled into a browser platform. After reporting the bug here:, a patch was committed into the WebKit nightly within 6 days. Here’s the background:

I frequently use the Web Inspector in Safari to inspect web pages in the iOS simulator. A recent bugbear for me is that as I inspect a style by drilling down the nodes and then refresh the page in the simulator, the selection of the element within the DOM tree is lost. It returns to all DOM elements being collapsed inside the root node (meaning you have to tediously drill back down, opening each node). I wanted to be able to refresh and the Web Inspector retain that position (giving it parity with the Chrome Dev Tools).

I didn’t need to create a reduction here as the behaviour could be repeated anywhere. Off the back of opening the issue, this problem is now rectified; if you use the WebKit nightly, and open the Web Inspector you’ll see that this amendment is now integrated. Lovely.

Another result with minimal effort on my part.


My final experience has been with Chrome (Blink, Chromium et al). I run the Dev version of Chrome day-to-day as it gives me a stable environment but a decent head start on the new shiny stuff that the Chrome team pushes out on a regular basis (although I often use Canary I find it a little too temperamental for everyday use and Stable is only for muggles).

I was noticing some odd behaviour with rounded corners (using border-radius) being applied to CSS tables. When they were applied, the border wasn’t rendered; instead a white/transparent border appeared. I created a reduction on CodePen to illustrate the issue and opened a ticket on the Chromium project issue tracker.

Within 3 days the issue had been identified as a regression bug and a patch is currently in the process of being integrated. The good news is that ‘muggles’ won’t even know about it and I and you/I don’t have to worry that about rounded CSS table corners being borked.


I implore you, when you find something that seems like a bug, to follow the advice in Lea Verou’s article. Create a reduction (which for me often reveals it was merely an ‘error between keyboard and chair’ on my part) and if needed, file a bug with the relevant vendor.

Each time I have done this it has been entirely worthwhile. Either I’ve learnt something or things have been fixed up. In my book, either way, that’s a good deal for the meagre time investment involved.

Bug tracker links

Safari bug tracker
Chromium project bug tracker
Mozilla bug tracker