We ask a panel of experts: how can you tell if a problem on your site is your code's fault, or the browser's?
Your new site is not behaving how you'd expect – but how do you know if the bug is hidden in your code, or if it's a browser issue? We asked the experts.
Always make a reduced test case. That way you're eliminating the possibility that the bug is in your code or a framework. It will also help you define the triggers for the bug appearing. Once you have that reduced test case that shows the bug, have someone else check the code. We all make mistakes because we're too familiar with our code. Never be afraid to file a bug that includes your test case – that's the best way to get fixes prioritised by vendors.
Of course, you test in all browsers, right? So if you're seeing a bug in every browser, then it's probably your code. Make sure you're testing across the full range, though – because different browsers can share the same rendering engine; Opera and Chrome, for example, both use the Blink rendering engine, so will exhibit the same browser bugs.
To narrow it down further, validate your code with validator.w3.org, check your CSS at jigsaw.w3.org/css-validator and look in your DevTools console to catch any JS errors.
If only one rendering engine is misbehaving, please, please, please report the bug to the browser. We love fixing bugs and it makes everyone's life better. Steve Faulkner has a great guide to reporting bugs.
Bruce Lawson is an open standards advocate for Opera
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
In order to be able to tell if a bug is yours or the browser's there are a few things you can do. The first is really to test your assumptions. Is what you're experiencing really a 'bug' or just 'not what you expected'? There are numerous examples where a browser does something different to what you want it to do because this is how it was defined in the standard. That's why it is important to check on this to validate.
As developers, we often expect things to be as easy as abstractions like libraries and preprocessors make them for us, but having the same functionality in a browser would make it perform horribly slowly.
In any case, there are a few ways to find out if the browser's buggy or if you did something wrong:
Test what you do across different browsers – if they all display it 'wrong', it's most likely you made a mistake
If only one browser 'does it wrong' search that browser's bug-tracking tool. You might find a bug listing and a workaround that way. If not, please file a new bug – you can help make browsers better that way
Check the error log of the browser console – most browsers now have human-readable errors
Use developer tools to track down what is really happening. Development these days is a lot more complex than it used to be – preprocessors and libraries and their interaction can throw a lot of spanners in the works. Use the black box features in Firefox 1, for example, to ensure you really only debug your code – the error might be caused by a library you used
Set breakpoints and go through your code step by step – there might be a missing variable or one in a different format than expected
Check the network tab to see if dependencies weren't loaded or had a wrong MIME type, or a font wasn't loaded
Check the settings of your local server – often resources are not sent in the wrong format, and make the browser choke
Browsers aren't perfect, but they can be improved. It is much more likely though that somewhere in your code something went wrong, than that a browser is genuinely broken. It does feel much better blaming the browser than finding out what went wrong at our end, so it is natural to go for that.
If you get a different result in every browser (assuming all the features you're using are supported in every browser you're testing in), then you've definitely stumbled upon a browser bug!
Of course, your job is not done yet: you need to reduce it down to its bare essentials before reporting it. Firstly, because otherwise you have no idea what the bug is exactly, so how can you search if it's already been reported? Secondly, because the more accurate your bug report is, the higher your chances for getting it fixed – soon. I wrote an article about creating bug reports a few years ago, and most of it is still pretty relevant.
You also need to figure out which browser is buggy by reading the relevant specification. You might be surprised to find that sometimes more than one of the browsers you tested will be buggy. For example, I was recently testing the 'resize' property on pseudo-elements, and it turned out both WebKit/Blink and Gecko were buggy in different ways, so I had to file three bug reports!
Now, when you're testing a feature only supported by one rendering engine, or when you get the same result everywhere but you suspect it's incorrect, it's more difficult to know if you've actually stumbled on a bug. Again, your best bet is to isolate the issue as much as possible, then read the specification and compare the expected result with what you're getting.
Don't rule out the possibility that the specification itself is buggy – specs are written by people, and are far from perfect. In that case, you need to report the issue to the appropriate W3C mailing list (www-style for CSS). Don't be shy – standards folks love getting comments from authors about how these specs are used in the wild. Even if it turns out not to be a bug, your input is invaluable!
If you think you've got a browser bug on your hands, create a test case – this is an example of the bug using the very least amount of code it takes to trigger the unexpected effect or error, ideally removing any uses of libraries and other dependancies. 99 per cent of the time, just going through the motions of stripping back your code to the bare bones will help you identify that the mistake is your own, and for that 1 per cent that it's not, you've got an example of the issue to report to the browser developers.
Frances Berriman is a senior designer and frontend engineer
This happened to me recently. I isolated the code into a demo on JS Bin to make sure nothing else I'd written was causing it, and narrowed it down to a couple of lines of CSS. I tested the demo on different browsers and devices, and realised the bug only appeared in the latest version of webkit for elements with repeating background images, a background colour and a CSS transform! To help anyone else that came across the same problem, I submitted a bug report.
As a web developer, I always blame the browser makers because I know I never write buggy code! In all seriousness, 99 per cent of the time I'll assume that an error is associated with the code that I write simply because browser makers do a fairly good job of capturing a lot of the issues ahead of time.
Browser-based debugging tools have evolved tremendously allowing you to drill down into issues fairly easily. Couple that with a good linting tool like JSHint, and in most cases you can easily identify developer-caused issues.
A key indicator that something may be up on the browser side is when the same code fails across different browsers. That's usually an indication of differences within the feature implementation, at which point a reduced test case needs to happen. This is why it's always recommended to test browsers in their native environments, allowing you to see the actual rendering and account for nuances of each OS.
I tend to use JSBin or CodePen for creating the reduced test scenarios since these make it incredibly easy simple to create the markup and JavaScript snippets to simulate your code. And once you've pinpointed that it is a browser-based issue, please be sure to report it. It's too easy to assume someone else will, so taking the extra step to file a bug does make a big difference.
