Help The Community: Report Browser Bugs

Advertisement

You’re developing a new website and have decided to use some CSS3 and HTML5, now that many of the new specifications are gaining widespread support. As you’re coding the theme and thinking of how much easier these new technologies are making your job, you decide to stop for a while and test in other browsers, feeling a bit guilty for getting carried away and having forgotten to do so for a while. “Please work,” you whisper to your computer, while firing up all of the browsers you have installed. Browser A, check. You smile, feeling a bit relieved. Browser B, check. Your smile widens, and you start to feel better already. Browser C, “FFFFUUUUUUUUUUU…!”

Sound familiar? You might be surprised to hear that this is not necessarily your fault. With the competition in the browser market these days and the fast pace at which the new specifications are developing, browser makers are implementing new stuff in a hurry, sometimes without properly testing it. CSS3 and HTML5 are much more complex than their predecessors. The number of possible combinations of new features is huge, which leads to the most common cause of bugs: two (or more) things that weren’t tested together. As a result, developers these days stumble upon browser bugs much more frequently than they used to.

Why Should I Bother Reporting Bugs?

If you don’t, perhaps no one else will. Maybe the bug you’ve discovered is so rare that no one else will stumble on it. Or maybe they will, but they won’t know how to report it. They might think that it’s their fault, just as you originally did. Besides, if you’ve used these new technologies in a way that triggers the bug now, you will likely do so again in the future as well, so you would directly benefit from the bug getting fixed. And in the process, you’d be helping thousands of other developers avoid the frustration you’ve faced.

You might think that reporting the bug would be pointless, because it would take ages to fix, and would take even longer for users to upgrade to the fixed version. However, for all browsers except Internet Explorer (IE), this is not true anymore. Users of Firefox, Opera, Safari and Chrome upgrade really quickly these days, because the software pushes them to do so or (in the case of Chrome) doesn’t even give them a choice. Also, some bugs get fixed quite quickly, especially the ones that come with a decent report. Keep reading, and your own bug reports will likely fall in this latter category.

Making A Reduction

The first step is to reduce the problem to its bare minimum. If it turns out to be a browser bug, you will need to include this “reduction” in your bug report. Also, this will help you figure out a potential workaround until the browser vendor fixes it. Even if it’s not actually a browser bug, doing this will help you realize what you did wrong and fix it. Lastly, it’s a valuable aid in debugging in general.

Here is the process I follow to create reductions:

  1. Make a copy of your project. If it includes server-side code, then first save the rendered page locally; the rest of the process will be identical from this point on.
  2. Start removing CSS and JavaScript files. Eventually, you’ll find that removing one makes the problem go away. Add that one back and remove the others (except any files it depends on). In some rare cases, you might find that the bug persists even after removing all CSS and JavaScript code. In these cases, the bug is more than likely HTML-related.
  3. Now you need to find the exact code in the file that triggers the problem. Start commenting out parts of the code until the problem goes away (being careful not to introduce any new problems in the process). I find that the quickest way to do this is like doing a binary search: first, comment out around half of the code; if the bug persists, then remove that code and comment out half of the remaining code, and so on; if the bug disappears, then remove the uncommented code and proceed with that. You might find that deleting and undoing is quicker than commenting and uncommenting. Sometimes you have to do this process twice in the same file, because some bugs can be reproduced only with a particular combination of different code parts.
  4. Put the remaining CSS and JavaScript code inline by transferring it from the external file to a <style> or <script> element in the HTML document. This will make the reduction even simpler because it will be contained in only one file.
  5. Now, simplify the HTML. For example, if it’s a CSS bug, then remove everything that CSS rules don’t apply to. If the rules apply to a nested element, try applying them to the <body> instead and see whether the bug reproduces. If it is, then remove all of the <body>’s descendants.
  6. Change the document’s <title> to something relevant to the bug. Check the whole thing carefully for details that you wouldn’t want other people to see, because you usually can’t edit it after attaching it to your bug report. (I learned this the hard way.)

Now that you have your reduction, examine the code. Is it actually correct? Browser makers can’t be held accountable for the way their products handle invalid code — except for HTML5 markup, which has strictly defined error-handling. Validating the code might help, but take its output with a grain of salt. (Note that CSS vendor prefixes are valid, even if the CSS validator1 disagrees.)

If you have some time and want to be extra nice, here are some other things you can do to make an even better reduction:

  • Test to see whether the bug is more general than the case you have discovered. For example, if you discovered that an engine doesn’t handle border-radius: 50% correctly, then test whether the same thing happens with other percentage-based values. Or if a CSS gradient from black to transparent does not display correctly, see whether the same thing happens when you use a transition from background-color: transparent to background-color: black; if it does, then that would mean the problem stems from general interpolation and is not limited to CSS gradients. Even if you find that it’s not more general than the case you originally stumbled on, do mention your experiments in the bug description, so that the developers don’t have to repeat them.
  • Try to find a workaround. Can you change or add something in the code to make the bug go away? This could be as easy as converting ems to pixels or as hard as adding a whole new declaration2. Be sure to mention the workaround in the bug report.
  • Make it function like a test case, or create an additional test case. These are the special kinds of reductions that QA engineers make for automated testing systems. Such tests show the color green in browsers that don’t have the bug and red in the ones that do. Other colors may be shown, but not red and green at the same time. This is an easy task with some bugs, and incredibly hard with others.

Sometimes the nature of the problem is quite obvious, so creating a simple test case from scratch is quicker. I’ve found JsFiddle3 to be an invaluable aid in this. However, bear in mind that browser vendors usually prefer that you upload your own simple HTML files rather than provide JsFiddle links. If you do decide to use JsFiddle, then uncheck the “Normalized CSS” setting, remove any JavaScript libraries (unless your bug needs them to be reproduced), and append /show to the URL, so that it leads only to your test case, without the rest of the JsFiddle UI.

If you don’t have the time to make a reduction, reporting the bug is still a good idea. A bad bug report is better than none at all, and the same goes for reductions. In this case, the browser developers will have to create the reduction themselves. The difference is that they’re burdened with doing this for many more bugs than you can imagine. You only have to do it for one: yours.

Should I Report It?

There are many reasons why you might not need to report the problem as a bug after all:

  • It turns out it’s not really a bug,
  • It has already been fixed in the latest nightly build,
  • It has already been reported.

Let’s tackle these one by one.

Is It Really a Bug?

In most cases, when you isolate the problem to a simple reduction, it’s fairly obvious whether it’s a browser bug or not. However, there are some caveats to this.

A while ago, I realized that even though outline-color: invert was in the CSS specification, it didn’t work in all browsers that support outlines. In particular, it didn’t work in Webkit browsers or Firefox. Those browsers didn’t drop the declaration, but just treated it as though it was currentColor4. So, I went ahead, created a reduction5, and filed bug reports with both browsers. After a while, I was informed that a footnote in the specification actually permits user agents to do this, so it wasn’t actually a bug. The moral of the story is to check the specification carefully — not just the table that is included in every CSS property, but the whole thing. Knowing these details will make you a better developer anyway.

On another occasion, I was reading the “CSS3 Backgrounds and Borders” module6 and found that it allowed percentages to be used for border-width, unlike CSS 2.1. I tested it, and it didn’t work in any browser. So, I filed bug reports7 in some of them, only to be informed that this was dropped in the “dev” version (i.e. the not-yet-published version) of the specification. The moral of this story is that, for specs still under development, don’t check the published specifications to determine whether your issue is actually a bug. Instead, look at dev.w3.org8, where the most up-to-date versions of the specs reside.

Of course, in many cases, a bug is not really a bug or a lack of understanding of the spec, but just one of those stupid mistakes that we all do (aka brain farts). I remember once how distraught I was over my JavaScript not working at all in Safari, even though it gave no errors. After a while of struggling to make a reduction, I realized that I had previously disabled JavaScript in that browser to test how a website worked without it and had forgotten to enable it.

Likewise, a few days ago, my SVGs weren’t displaying as backgrounds in Firefox, even though they displayed when I opened them in new tabs. I then realized that I had two background images in the same declaration, the other one being a CSS gradient, and I had forgotten to add the -moz- version.

The one I’m most embarrassed about is when I actually reported a bug to Opera about pointer-events not working in <select> menus and was then informed that Opera hadn’t implemented pointer-events in HTML elements at all. D’oh!

In some rare cases, the bug is indeed a bug but not a browser bug. Specifications have their fair share of bugs, too. If the spec defines something other than what happens or if it defines something that conflicts with the rest of the spec, then it most likely has a bug. Such bugs should be reported in the relevant mailing list (www-style9 for CSS) or the W3C bug tracker10. Even if this is the case, many of the guidelines mentioned below still apply.

Is It Reproducible in the Latest Nightly Builds?

If you haven’t already installed the nightlies of browsers, you should. These are the latest (potentially unstable) versions of browsers. Download them from these links:

Obviously, if your bug is not reproducible in the latest nightly of the browser, then you don’t have to report it. Just wait until the build propagates to a stable release. In other words, all you need is patience, young Padawan.

Has It Already Been Reported?

If after checking the specifications and the latest nightly, you’re still confident that it is a bug, then you need to search whether it has already been reported. Your best bet is to use the search engine of the relevant bug tracker. Don’t forget to search all statuses, because the default on some bug-tracking systems is to search only confirmed and open bugs (excluding unconfirmed and fixed or otherwise closed ones).

Be vague in your search, especially if the bug affects a feature that’s not very popular. For example, for this Webkit bug16, a search for “multiple file17” would show the bug, whereas a search for “input file multiple dom property18” would not; I was inexperienced when I filed it and didn’t know the exact terminology at the time. If the bug tracker is public, sometimes searching on Google also helps (adding site:url-of-bug-tracker after your keywords).

If your issue has indeed been reported, some bug trackers allow voting. Mozilla’s Bugzilla gives every user a limited number of votes (the limit is in the thousands), which the user can use on any bug they wish. Also, Chrome’s bug tracker features a star in the top-left corner, which you can click to indicate that you consider the bug important. I’m not yet sure whether the developers take this into account, but voting certainly doesn’t hurt.

Different Engines, Different Bug Trackers

Every browser has its own bug-tracking system (BTS).

Safari and Chrome share the same engine (Webkit), so bugs that can be reproduced in both should be reported in Webkit’s BTS. Chrome has its own BTS as well, intended for bugs that are reproducible only in it. Also, if you’re dealing with a JavaScript bug in Chrome, report it to the V8 bug tracker28.

You will need to create a free account to file bugs with any of these bug trackers (except Opera’s Wizard). But it’s a one-time thing, and it’s useful because it allows you to easily track bugs that you’ve reported.

All of the browsers’ bug trackers are public, with one exception: Opera’s. You can report Opera bugs through the public form I linked to above, but to access the BTS and to discuss your bug and monitor its progress, you will need to become an Opera volunteer (or an employee!) and sign an NDA. Volunteering is by invitation only, but if you submit a lot of good bug reports, there’s a good chance you’ll be invited.

Filing A Good Bug Report

The most important part of a good bug report (and the one most commonly done wrong) is the reduction. Hopefully, you’ve done that already, so the hardest part is over with. The rest probably won’t take you more than five minutes.

Providing a Good Summary

A good summary is the second-most important part of a bug report. Don’t be afraid to be verbose, if it actually adds something (don’t just babble). To take one from an actual report29,

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

… is better than “Background image disappears when body{display:table} is used,” which in turn is better than “Disappearing background image.” Of course, all three are better than “CSS broke. Please fix!!!!11”

Sometimes you may want to add keywords to the beginning of the summary to make the report more findable. For example, if your bug is about CSS3 gradients, you could prepend the summary with “[css3-images].” To get an idea of the exact tags used in a module, look at other bug reports. It will usually be the same as the id of the specification, which is located at the end of its URL path. For example, for the CSS3 module “Backgrounds and Borders30,” the URL is http://www.w3.org/TR/css3-background/31, and the spec’s id is css3-background. Also, these summary “tags” can be OS-specific. For example, if your bug is reproducible only in Mac OS X, then prepend your summary with “[Mac].” If the bug is about something that used to work fine in previous versions, then prepend your summary with “[Regression],” or add “regression” as a keyword if the BTS has such a feature.

Categorizing the Bug

The category to which your bug belongs is usually quite obvious, provided you take a few seconds to check them all. For CSS bugs, these are the most common candidates:

  • Internet Explorer: “CSS and HTML”;
  • Firefox: “Style System (CSS),” all the “Layout” components;
  • Opera Wizard: “Web page problem”;
  • Webkit: “CSS, Layout and Rendering”;
  • Chrome: doesn’t let you categorize bugs (its developers do it for you).

John Resig suggests some ways to categorize JavaScript bugs32.

Other Fields

  • You can be as verbose in the “Description” field as you need to be. Explain the bug in detail (what you expected to see, what was actually displayed, etc.) and any interaction needed to reproduce it. Then mention any workarounds you found, how other browsers handle the case, and any other notable observations. But don’t start babbling about what you were doing when you discovered the bug, no matter how funny or interesting you think it is. QA time is precious; please don’t waste it with irrelevant detail.
  • The “Product” will usually be “Core.” If you have a choice between “Core” and the browser’s name, choose “Core,” because bugs filed under the browser’s name are usually for the UI.
  • Regarding “Platform” and “OS,” try to test in other operating systems if you can. (You do test your websites in different operating systems, right?) If the bug is reproducible in all OS’, then select “All.” If it’s reproducible in only one, then mention that in your description and/or summary.
  • Avoid changing the “Severity” or “Priority” fields, because you will tend to overestimate.
  • Most people who report bugs don’t fill in the “CC” field. But if you know someone who works for a given browser vendor, especially someone who frequently replies to similar bug reports (browse the reports if you’re not sure), then cc’ing them might help the bug get noticed more quickly. In some cases, this could mean the difference between a bug report getting noticed in a few days and one going unnoticed for months.
  • If you have the time to take a screenshot, by all means do so, especially if the bug is reproducible in only one OS.

What Not to Do

Never, ever report multiple bugs in the same report. Handling these is very hard for browser developers. Think about it: what status should they assign to a report if they fix one bug, but the other turns out to be a duplicate? Or only one of the two turns out to be a bug? You get the idea.

I can understand that you might be frustrated from having had to deal with that bug, but being rude won’t help. Stay polite, and keep thoughts like “I can’t believe you can’t even get this right, you morons!” to yourself.

Some Examples

Example 1: Reducing the Original Problem, Realizing It Was Your Mistake

While developing twee+33, a handy little app for posting long tweets (and my entry in the 10K Apart contest34), I found out that even though it worked in mobile Safari for reading, it crashed when you tried to make an edit. I had no idea what might have been causing this, so I made a copy and started reducing. After commenting out parts of the JavaScript, I found that if I removed the onresize event handler, the problem stopped occurring. And then it made total sense: I adjust the rows of the textarea when the user resizes the window. However, in Mobile Safari, this triggered a resize event, resulting in a dreaded infinite loop. So I removed the resize event handler for mobile. It’s not like the user can resize the window there anyway.

Example 2: Making a Reduction From Scratch, Filing a Bug

A big part of my upcoming CSS3 workshop in Amsterdam35 is hands-on challenges. Attendees will download my slide deck (which is essentially an HTML + CSS + JavaScript app) and try to solve some 5- or 10-minute challenges on everything taught. A challenge slide would look like this:

36

I prepared a lot of the slides in Chrome. When I opened them in Firefox, I was greeted with this ugly sizing of the textarea:

37

In this case, I didn’t follow the reduction process laid out above, because I had a hunch that the bug was related to the way I sized the textarea. So, I fired up JsFiddle and made this simple example38, in which the bug could still be reproduced. I then tested it in Opera and observed that it behaved like Firefox, so it was probably Webkit that was buggy. I tested it in the Webkit nightlies and saw that it hadn’t yet been fixed.

Before going any further, I tried to see whether the bug was more generic. Does it happen only with textareas or with all replaced elements? I went ahead and tested <img>39 and <input>40 and found that it happens only with form fields. I did another test to see whether it also happened with top/bottom rather than left/right. It did not41. I also tested on Windows, and it’s reproducible there as well.

The specification42 confirmed that it was indeed a bug: “The used value of ‘width43’ and ‘height44’ is determined as for inline replaced elements45.” After a bit of searching on Google, I found this blog post46, which describes the bug but does not mention an official bug report. So, I searched Webkit’s bug tracker for “textarea absolute,” “textarea positioned” and “input positioned” and couldn’t find anything relevant. It was bug-reporting time!

I went ahead and created this bug report47. Let’s hope it goes well.

What Happens Next?

At some point, usually after a few days or weeks, someone will modify your bug’s status. If it turns out to be a “duplicate,” don’t feel bad: it happens to the best of us, even employees of the browser vendors themselves. If the status gets “confirmed” (usually with the status “new”), this is a good indication that it is indeed a bug and that you did the right thing by reporting it. Last but not least, if the new status is “assigned,” it means someone is actively working on the issue (or plans to do so soon), so it has a high chance of getting fixed soon.

When your bug gets a status of “resolved,” check the “resolution” field. If it says “wontfix,” it means that they’re not planning to rectify the issue, for reasons usually stated in detail in an accompanying comment. The reason is usually either that it’s not a bug (in which case, the most appropriate resolution status is “invalid”) or that they just don’t want to work on it for the time being. If the latter, you could argue your case and explain why the bug is important, but don’t get your hopes up. Last but not least, if it’s “fixed,” you can congratulate yourself on doing your part to make the Web a better place.

Further Reading

Thanks a lot to David Storey53, Divya Manian54, Paul Irish55, Elika Etemad56 and Oli Studholme57 for their helpful tips and reviews.

Front Cover: Image source58

(al)

↑ Back to topShare on Twitter

Lea works as a Developer Advocate for W3C. She has a long-standing passion for open web standards, which she fulfills by researching new ways to use them, blogging, speaking, writing, and coding popular open source projects to help fellow developers. She is a member of the CSS Working Group, which architects the language itself. Lea studied Computer Science in Athens University of Economics and Business, where she co-organized and occasionally lectured a cutting edge Web development course for 4th year undergrads. She is one of the few misfits who love code and design almost equally.

  1. 1

    Great article Lea.

    The only thing I would add is people should not forget to test their bugs (and reductions) in a clean environment, meaning no weird addons/plugins that can cause their share of problems. An “out-of-the-box” OS installation in a Virtual Machine works great for this.

    0
    • 2

      Very good point! Although I do suggest they try it in the latest nightly, in which many extensions won’t work anyway.

      0
  2. 3

    Strange thing is, I encounter a lot less “bugs” (or rather differences between browser rendering) than I did say 6 or 7 years ago?

    0
    • 4

      Yes, browsers are much less buggy with the established standards (CSS 2.1, HTML4, ES3 etc). I tend to come across lots of bugs with the new technologies though, like I said in the articles.

      0
      • 5

        Hi Randy,Thanks a lot for your comment, and you could smilpy create the folder structure by creating folder structures under collection section in iDocument, or you could smilpy drag and drop your previous created structured folders into the collection section to keep the structures.Thanks in advance;Mikeicyblaze.com

        0
  3. 6

    Don’t forget to test the same issue in multiple browsers. If the same results occur in Firefox, Chrome and Opera then it’s likely *not* a bug and just your misunderstanding of the spec.

    0
    • 7

      I mention that in the intro. The whole article assumes that this is the case. But yeah, good job pointing it out, as it’s important :)

      0
  4. 8

    Curious how Browser C almost exclusively has the word “Internet” in its name :D

    0
  5. 9

    Can I just say that the little app you’re making for your css3 workshop looks like a lot of fun. Are you thinking of making it available to the front-end web dev. community after your workshop is completed?

    0
  6. 11

    Help the community, don’t use Browser C !

    0
  7. 12

    There’s no point reporting Firefox bugs because the developers don’t care about them. I stopped bothering years ago.

    There are shocking bugs that would be simple to fix but they have been there for YEARS – usually because the developers refuse to accept it as a bug – or are unable to reach a consensus.

    E.g. Saved usernames and passwords are NOT case-sensitive – so sometimes FF saves it wrong, making it impossible to login. And you cannot change the saved credentials unless you create a new profile.

    0
    • 13

      I’ve never reported UI bugs, but my experience with reporting Gecko bugs isn’t that bad. Yes, some bugs always stay unresolved for years, but that’s true for every browser/engine.

      As to how simple some bugs are to fix, let’s not speculate without seeing the code (don’t you hate it when your clients do the same and assume you can do something in 10 minutes when it actually takes hours? ;) And if you’ve seen the code, and it is indeed easy, why not submit a patch? :)

      0
    • 14

      As weird as you might see it, I see and feel that way about Chrome and Webkit. There are a few immortal bugs that have been there for more than 2 years and sadly most are are just CSS1 and plain ole HTML4.
      sample Webkit bug, for which I just created a fresh reduction and can repro on all Webkit targets: https://bugs.webkit.org/show_bug.cgi?id=24441

      sample Chrome bug, haunting my projects for ages: http://code.google.com/p/chromium/issues/detail?id=24524

      or this other, showing how bad font rendering has been on Chrome for more than 2 years, and even worse with an infinite discussion on how this is or isn’t a bug: http://code.google.com/p/chromium/issues/detail?id=23440 (hint: it is a bug.)

      Btw, nice article Lea. Reporting bugs is a really tiresome task that only pays in the long run, but someone has to do it if we want to have a better environment for creating awesome stuff.
      I always keep a piece of paper with notes on the stuff I need to make reductions for, it’s a really nice reminder to force you into doing it or your desk will have that zombie piece of paper forever.

      0
  8. 15

    With regards to Browser C (internet explorer), isn’t the scene still pretty sad ? I mean since the people who use it are still in majority (if you talk about the world) and they do not bother upgrading it, we have a substantial number of folks using the good old IE 7, 8. Can’t the MS people simply force the users to upgrade? It’s such a nonsense. Now everytime a new IE version comes out, more stylesheets have to be added! x(

    What is the point of employing new technology at this stage when you are in fact doubling your work making things right for IEs? When you encounter a bug in IE 7 or 8, then it wont help reporting it since it will likely be fixed in subsequent versions which as we all know a lot of people will not use.

    Also, I do not understand why there should be vendor prefixes at all? It’s like they are simply being lackadaisical about resolving this relatively easy issue. You need to write 4-5 statements in css to achieve the same effect across all browsers. That is just atrocious. I think we should report that
    border-radius not working in FF is a bug. Prefixes should only be necessary where syntaxes differ owing to coincidentally similar developments taking place in browsers. Even then, they should be able to reach a consensus. But unless we start putting pressure on them, they probably wont bother!

    0
    • 16

      “Browser C” was not a euphemism for IE. I’ve found bugs in every engine. I’d say most were Webkit actually, but I use Webkit, Gecko and Presto far more than Trident (IE’s engine), so it might just be that my exposure is less to it.

      Prefixes are mandatory for browsers implementing stuff in specifications that haven’t reached Candidate Recommendation status yet, because Working Draft specs are in flux. Also, regarding prefixes: http://www.alistapart.com/articles/prefix-or-posthack/

      0
    • 17

      I just wanted to add a quick note about automatic upgrading: I recently spoke to members of the IE team and unfortunately due to a number of factors automatic updates to IE6/7 are not going to be something you’ll see occurring on a widespread basis.

      The reason for this is that one of the largest groups still using these older browsers are government departments who have locked down systems (and browsers) which their employees can use. For security reasons, it’s going to be another while yet before IE6 is completely dead.

      For the other groups using older C-grade browsers, all we can really do is improve education and awareness around why it makes sense to upgrade. The industry helped get a lot of people off IE6 and the same will happen with IE7 and 8. Just give it time :)

      0
      • 18

        In case of India, it is very sad that even private banking systems are optimized ONLY for IE. The portals don’t even work on FF and webkit!

        That’s a good explanation about govt departments using IE 6. But you know the thing is, there is persistent lethargy in govt departments when it comes to these things. It’s easy to say that IE 6 will be dead but I have my reservations. Security will always remain an issue. Unless an active awareness program is started ONLY for the govt departments, I doubt IE 6 will vanish even in the next 4 years.
        Our only hope is that the old machines will simply get too old to run. :P
        Sorry for going off topic.

        0
    • 19

      “Can’t the MS people simply force the users to upgrade?”

      Maybe if they buy for everyone a new operating system. My whole country still lives on XP, where IE9 refuses to run. Spend 300 euros for a “free” browser? Hahaha. People aren’t sure what a browser is anyway. “I use the yahoo?” (quote from when Google asked people in the streets which browser they use)

      Also, notice how Mozilla’s new 6-week-sprint is making enterprise rethink using Firefox. Enterprise needs a browser that goes through long periods of stability. Unfortunately that has been IE for most companies.

      0
      • 20

        Yeah I completely agree. A lot of people still see XP as a perfectly good OS, and MS just does not want (can’t apparently) release IE9 on it.

        As for your last point, I think the whole software industry has entered a second golden age. We’re constantly working on innovating and improving web experiences, but most companies developing highly complex software just want a stable environment that will hold their frameworks together. It’s a constant chicken and egg scenario and evolution but we’ll get there :D

        0
  9. 21

    Thank you for posting the links to the main browser vendors bug reporting tools. I’ve got two bugs for iOS mobile webkit, but I haven’t been able to figure out where to direct them. Does anyone have a good way to submit those?

    0
  10. 22

    Excellent article.

    As a representative of a closed bug tracker (Opera) I fully understand the frustration of a report disappearing into a seemingly black hole, not being fixed for a long time. However, any complete, well written report with a reduction helps us prioritize. Even if it turns out to be a duplicate it is an indication that real people care about the issue and would like to see it fixed.

    Everything we do is a matter of priority, so it may still take a while. But submitting a good report will never hurt your chances of getting something fixed.

    0
    • 23

      I don’t bother reporting Opera bugs. 500 other people might have spent their time reporting it. I have web sites to build that work today, meaning instead of writing some bug report that ends up in the abyss (or worse, I get told that 2 browsers doing it one way and 3 browsers doing it the other way is perfectly legal, meaning it’s absolutely worthless for any developer to actually bother using on a site), I will spend the time to find a work-around that works today.

      Best way to spend development time.

      0
  11. 24

    Good article with a very important message. I’ve been submitting bugs for all the major browsers for some years now.

    I need to mention the poor support I get from Apple regarding their Safari browser. I’ve tried to submit issues with JAVA plugins – I’ve even paid for premium support and not got anything done from Apple.

    I know that Safari is build upon the webkit engine but some of the bugs are related to the OS and browser implementation.

    Have any of you had success with submitting bugs for the Safari browser? The three I’ve submitted got rejected with “Apple don’t support applications build with HTML” :-)

    0
  12. 25

    how about ie just follow w3c and then we might not see css comments like this….

    0
  13. 26

    Great article!

    A few things. If you have something that is “invalid” but still is handled differently by different browsers, file a bug. All specs should cover handling of invalid content these days (if the relevant spec doesn’t, file a bug on the spec, too).

    The other thing is if a browser crashes or hangs or goes into an infinite loop while other browsers don’t, file a bug even if it’s “your fault”. Maybe the browser can do something clever to avoid it. (It’s possible that other people will use the same pattern and don’t test in that browser.)

    0
  14. 27

    Vangelis Makridakis

    September 8, 2011 2:48 pm

    Μπράβο Λία και εις ανώτερα!
    Great reading and nice to point out what every user should do at the “spare time” browsing around… better contribute for a bug-free product we all use than leave it always to others.

    0
  15. 28

    However, in Mobile Safari, this triggered a resize event, resulting in a dreaded infinite loop. So I removed the resize event handler for mobile. It’s not like the user can resize the window there anyway.
    There are more and more Browser now. It is a difficult to Web Designer. My site discount-laptopbattery.com has something error in FF.

    0
  16. 29

    Nice article! A little too long though :) Unfortunately, not all companies read those bug reports. I have reported to Chrome that they have errors when animated GIF images that are of different extension are not always displayed properly.

    I have given them http://preloaders.net and some other online animated GIF generators with previews as an example – no reply followed.

    0
  17. 30

    Nice article, you made some good points about sending reports. We recently did a story similar about cross browser testing and problems with IE:

    http://www.back40design.com/news/m.blog/22/cross-browser-testing-why-it-s-important

    0
  18. 31

    I thought there was a real bug on my screen XD

    0
  19. 32

    My career in web design has been strange. My second bug discovery was the IE7 Guillotine bug which I discovered on Douglas Bowman’s site after coding CSS for about 6 months. It was fun to isolate.

    http://css-class.com/articles/explorer/guillotine/index.htm

    I presume most authors consider IE6 as the buggy browser but I say that IE7 is worse since it’s bugs need a kick to reveal. It was only this year that I discovered that I could still send different CSS to different browsers.

    http://css-class.com/test/css/parsing/escapes.htm

    I see that those at Mozilla has corrected Gecko parsing with the release of Firefox 6.

    Sometimes I wish I never discovered CSS since it has taken years away from other pursuits and my offline folders are overflowing with test cases of not interoperability between browsers.

    0

↑ Back to top