On the utility of filing bugs

lundi 24 avril 2017 - 6 commentaires

During my five years working at Mozilla, I’ve been known to ask people to file bugs when they encountered an issue. Most of the time, the answer was that they didn’t have time to do so and it was useless. I think it is actually very valuable. You get to learn from that experience: how to file actionable bugs, getting deeper knowledge into a specification, maybe a workaround for the problem.

A recent example

Three weeks ago, at work, we launched a new design for the website header. We got some reports that the logo was missing in Firefox on some pages. After investigation, we discovered that Firefox (and also Edge) had a different behaviour with SVG’s <use xlink:href> on pages with a <base> element. We fixed it right away by using an absolute URL for our logo. But we also filed bugs against Gecko and Edge. As part of filing those bugs, I found the change in the SVG specification clarifying how it should be handled. Microsoft fixed the issue in less than two weeks. Mozilla fixed it in less than three weeks.

In October this year¹, all browsers should behave the same way in regard to that issue. And a four year old workaround will be obsolete. We will be able to remove the code that we had to introduce. Less code, yeah!

I hope this will convince you that filing bugs has an impact. You can learn more on how to file actionable bugs. If you’d like an easier venue to file bugs when browsers are incompatible, the WebCompat project is a nice place to start.

Firefox 55 should be released on August 8 and the next Edge should be released in September (maybe even earlier, I’m not clear on Edge’s release schedule) ↩

Commentaires

I think the quality of the bug report is sometimes less important than who files it.

When your product has so many bug reports, how do you pick out the useful ones? You'll naturally pay more attention to bug reports where you recognise the reporter's name, because you know the bug report will be useful. (It's the same with long public comment threads.)

That has an impact for sure. I made a point in this post to talk about actionable bug reports. Actionable bug reports (with steps to reproduce or even a testcase) have a higher chance of being acted on by the development team.

I absolutely agree with this from a community benefit point of view.

From a purely selfish point of view, I think it was sensible, even necessary, to write a polyfill. A polyfill works cross browser, is developed on your schedule and is deployed to all your users at once. Even with today's evergreen browsers you'd still be talking many months if not years before you could rely on native browser support.

That doesn't stop you doing both of course, but the bug report is unlikely to be much use for your current project.

Oh yes, the polyfill was necessary, don't get me wrong. It would have been nice to get bug reports filed at the time that polyfill was created though. That would have made it unnecessary much sooner.

Author of the polyfill here. Happy to hear that it will soon be obsolete!

In case anyone is interested, here's the backstory: at the time of writing the polyfill I was working on a client website. The SVG icons weren't showing up in Firefox. It took me quite some time to figure out that the base element was the culprit.

I wrote some JS to fix the icons in Firefox and needed a place to store it for future reference (besides the client's version control system), so I put it in a public gist, thinking maybe it would be useful for others too. I didn't relate to it being a polyfill, it was "just some code to fix this weird inconsistence" :)

I didn't think about filing a browser bug, because I wasn't convinced it was a bug at all. WebCompat.com only existed for a few months, so I probably hadn't heard from it yet :)

Today I came across the gist again and I'm really surprised at how many people use it, thank me for it etc. It's really warming to know I helped a lot of people this way!

As for this post, I absolutely agree it would be very useful to have filed browser bugs at that time. In later years I bumped into a Flexbox cross browser inconsistency, which I created a write-up for. And I filed a browser bug for it! :)

Thanks for that story and the original workaround. We didn't use it directly because we'd rather avoid running JS if we can and therefore fixed it in the HTML directly. But without it, it would have taken us way longer to find a solution.

That write up is impressive. Great thing it improved cross browser compatibility in the end. I see Daniel Holbert quickly got involved. He is so helpful with flexbox issues!