Help make web browsers better

You quietly impose another design and this time you decided to try CSS3 and HTML5, because now these new specifications are fully supported by most modern browsers. You have already set up a decent amount of code, from time to time thinking about how new technologies simplify your work and suddenly it took you a while to stop and check the page in other browsers for a while. You are already starting to get nervous, because the goat is understandable - such a test should have been carried out at much earlier stages. You run all the browsers you have, and whisper "Please, work" to your computer. Browser A, it works. You smile, you feel relieved. Browser B and everything is fine too. You break into a smile and your mood rises. Browser C ... "FUUUUUUUUUUUUUU ~!"


Perhaps you will be surprised, but not always this situation is a web developer error. In the current arms race on the market of web browsers and incredible progress among web technologies and specifications, the creators of browsers introduce new features in a hurry, from time to time even without proper testing. CSS3 and HTML5 are much more complicated than their predecessors, the number of possible combinations of new features goes off-scale, which is often the cause of the bug: two (or more) pieces were not tested together. As a result, browser developers devote much more time to fixing bugs than they should.

Why should I report bugs to developers?

If you do not do this, then it is possible that no one will do it. Perhaps the bug that you found is so rare that no one else will ever stumble upon it. Or stumble, but will not know how to inform the developer about it or think that the matter is not in the browser at all. In addition, if you used new technologies in your code in such a way that a bug appeared, then you are likely to stumble on it again in the same way, so that a quick fix for the error is in your interest too. And in the end, you will help thousands of other web developers avoid the bummer that you experienced.
')
Perhaps you think that it is pointless to report bugs, because it will take years to fix them, and it will take even longer for users to upgrade to a fixed version of the browser. I'll tell you a secret: all browsers, except IE, everything is much better. Nowadays, users of Firefox, Opera, Safari and Chrome update to new versions very quickly, thanks in large part to the browser developer — annoying windows with offers to be updated, promoting new versions, or even completely automatic silent updates without the user's knowledge (this is about Chrome ). Bugs are fixed very quickly, especially those that have been properly reported to the developers.

Find what causes the bug

The first step to a good report is to find the cause of the problem. In other words, we need to reduce the problem code to a minimum, so as not to bother the developers with unnecessary garbage. If the bug concerns the rendering of pages, then you should definitely attach the code causing the problem to the report. And even if you made a mistake, and the problem is not with the browser, then at least you will know about it, and experience is never superfluous.

Here is the algorithm by which I keep the code to a minimum:

1. Copy somewhere your project in the form in which you found the bug;
2. Open the code and start to gradually delete the contents of the CSS and JS files used on the page. In the end, after the next removal, you find that the bug is gone. In this case, return the remote code snippet back and try to get rid of everything else so that the bug remains. In rare cases, deleting CSS and JS may be meaningless, which means that the problem with HTML is most likely related to HTML;
3. Now you need to find a specific block of code that is causing the bug. Slowly and gently enclose the code snippets in a comment until the problem disappears. Personally, it is much easier for me to do this using the binary method: first, comment out about half of the code; if the bug remains, remove the commented code, comment out half of the rest and repeat the procedure. Unfortunately, cleaning the code from unnecessary garbage can be delayed - there have been situations when a bug manifested itself only when combining a certain code in a certain way;
4. Transfer the remaining CSS and JS code from files to an HTML page, wrapping it in style or script . This will make the report even neater;
5. Now it's time to remove the unnecessary HTML code. First of all, get rid of any identifying or personal information, then delete everything else. For example, if the bug is related to the operation of the CSS, delete all elements to which the style causing the bug is not applied;
6. Change the content enclosed in the title to something related to the bug.

Now you have a clean, readable code that causes this or that error, but first you should check it. Are you sure it is valid? Browser developers can not take into account the errors of web coders and do so that their product would normally process the code with errors. Alternatively, use online validators.

If you have extra time and you want to bring the bug report to the perfect look, you should do the following:

1. Try to make minor changes to the code, so you can find out the size of the bug. For example, if you find that the browser does not handle border-radius: 50% correctly border-radius: 50% , see if there is a bug with a different value (for example, 40%). Even if the bug does not appear, it is best to mention your experiments in the report, so that developers do not have to repeat them;
2. Try to make changes to the code that should not change anything in practice, for example, convert all values ​​from em to px . Again, regardless of the result, mention the work done in the report.

Even if you don’t have time to process the buggy code, make a bug report. A bad report is better than nothing. In this case, developers will be engaged in processing your code, but remember that they have to do the same with a huge number of other bug reports, so it will take much longer from publishing a report to correcting an error.

Should I report a bug?

There are several main reasons why you should not publish a report:

• In fact, what you took for a bug is not;
• The bug has already been fixed in the latest nightly-version;
• This bug has already been reported by someone else.

Let's walk for all three reasons.

Bug or not bug?

In most cases, if you cleaned the code of garbage and left only what causes the bug, you can very easily determine if the observed error is a consequence of the work of browser developers.

I discovered a long time ago that outline-color: invert does not work in all browsers. To be precise, it was about Firefox, Safari and Chrome. The listed browsers did not ignore this code, but processed it as if I was using currentColor . Of course, I cleaned the code, isolating the error, and created reports on the bug trackers of all the browsers listed. After some time, I was informed that the specification has a footnote, saying that browser developers have the right to handle this parameter in this way, so it turned out that the bug did not smell here. The moral is that before you publish a report, you must carefully read the specification of the allegedly buggy parameters. In addition, learning such features you gain valuable experience as a developer.

There was another case, I was scrolling through the CSS3 specifications and came across a description of the operation of the boundaries, where it was written that you can use percentages in CSS3 to indicate their width. Of course, my hands were itching and I decided to test this feature, however, no modern browser has rendered the code in accordance with the specification I read. I designed and published a bug report, which was answered to me, they say, this feature was removed from the latest, dev version (ie, unpublished) specifications. The moral of this story is simple: when you compare a bug with specifications, read the dev version instead of the published one .

Of course, it happens that web developers, like all people, are stupid. And it turns out that the bug is not a bug not because of unreadable specifications or an error in the code, but simply because of inattention. I remember my frustration when I couldn’t make one JS code work, even though no errors even fell out. As a result, I found that I recently disabled JavaScript in the browser and forgot to turn it back on.

I remember the most humiliating case in my practice. I designed a bug report and published it on Opera’s bugtracker, which described the situation when pointer-events did not work, being enclosed in select and as a result I was delicately informed that pointer-events are not supported by this browser at all.

In rare cases, the bug is indeed a bug, but it has nothing to do with a specific browser. Markup language specifications also sometimes contain errors. You should send reports on similar bugs to the developer sites of a particular specification (in the case of CSS, you need a W3C bug tracker ). Even in this exotic case, the instructions listed above still apply.

Has the last nightly build been fixed?

If you still haven't got the "night" versions of browsers, you should still do it. Here is a list of the most recent (potentially unstable) builds of the most popular browsers:

• IE 10 Platform Preview 2
• Firefox nightly
• Opera Next
• Chrome canary
• Webkit nightly builds

Obviously, if the bug does not appear in the latest nightly version of the browser, you should not make a bug report. Just wait for it to be fixed in a stable release branch. In other words, all you need is assiduity, young Padawan.

Has such a bug report already been done?

If after a careful re-reading of the specifications and installing the night build, you are still sure that you have a bug in front of you, you should search the bug tracker for a bug report describing your problem. Make sure that the search engine for bugtracker gives all the results, including unconfirmed and fixed bugs.

If the report is not found, try changing the search query, use synonyms, try to think through all the possible names of the desired reports.

Found that someone is ahead of you with a report? Do not rush to leave, some bug trackers (such as Bugzilla) support voting. I'm not sure that the developers take into account the bug reports rating, but if so, a high rating contributes to a more rapid elimination of the error found.

Different engines, different bug trackers

Each browser has its own bugtracker, intended for publishing errors found by users:

• Internet Explorer
• Firefox
• Opera wizard
• Webkit
• Chrome

Please note that Safari and Chrome are based on the same Webkit engine, so if the bug appears in both browsers, then you need to write on the Webkit bugtracker.

All bug trackers are public except one: Opera Wizard. You can send an error report to Opera, but you will not receive access to reports sent by other users, their discussion and correction progress. Only Opera volunteers and company employees have access to all these things. You can become a volunteer only by invitation (with the conclusion of a non-disclosure agreement), and getting a cherished invitation is not an easy task. Send all the errors you find, and you may be lucky.

Creating a good bug report

The most important part of a good report is code that has been cleared of unnecessary garbage. This is the hardest part, the rest will take no more than five minutes.

Good short description

A brief description is the second most important thing in a report. It is necessary to find the perfect balance, a brief description of the bug should not be too long and not too short. Here is a good example:

Background image disappears when body{display:table} is used (common CSS hack for correct centering + scrolling in Firefox)

In addition, you can add tags to the brief description to help other users find your report quickly and painlessly. For example, you can at the end attribute the operating system, a loaded parameter and, in principle, everything your heart desires, the main thing is that tags should be directly related to the bug.

basic information

Here, in principle, everything is very simple. Give a link to the cleaned code, share the results of your experiments with bugs, tell your personal opinion about the possible cause of the error. The main thing is less talk, more business. No need to talk about the fact that before finding a bug, you were picking your nose. Try to avoid any information that is not useful in the study of the error.

What not to do

Never, NEVER shove information about several different bugs in one report. This creates confusion and additional obstacles to the problem, this time.

Two, I can understand that some errors can annoy, interfere with and slow down the workflow, but rudeness will not help you. Stay calm, especially in the discussion of the report, and keep thoughts like “I just can’t believe that these assholes can't understand what kind of bug!”

What's next?

At some point, usually in a couple of days or weeks, someone will change the status of your report. If you are informed that this report is a double, do not worry, this happens to everyone. If your report was given the status "Confirmed", this is a good sign, indicating that you really found a new bug. Over time, the status will change to “Submitted”, which means that your report was sent directly to the browser developers and they will probably correct this error soon. When your report is categorized as “Fixed” - congratulate yourself, you have contributed to the development of the browser.

---

Original article: Help The Community: Report Browser Bugs
Posted by: Lea Verou
Date of publication: 07/09/11

---

This text is distributed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license .
You can copy, edit and use this text for non-commercial purposes with the obligatory indication of authorship and preservation of the original license.