It’s safe to say that the biggest tax on a web developer is spending so much time dealing with browser bugs and incompatibilities. Thus it has become the favorite past-time of all web developers to complain about having to deal with them. Browser bugs are annoying, frustrating, and make your job incredibly difficult.
Because browser bugs are so frustrating and such a burden on top of normal development it should be the responsibility of every web developer to make sure that the browsers they develop for are able to find and fix their bugs. By taking responsibility for the bugs that you find – and to not assume that “someone else will find it” – will accelerate the rate at which browsers can improve.
The solution to helping browsers is two-fold: 1) Every time you find a browser bug, file a bug report to the respective browser. 2) Actively test your sites in the latest builds of the major browsers.
The vast majority of web developers have never filed a bug report with a browser vendor – or even used a nightly version of a browser – which is a shame. If you think about it there are few who are more qualified to assess what is going wrong in a browser than those who spend every day developing for them.
I’m especially surprised when I see professional developers not filing bugs with browsers, or testing on nightlies. Since one of the primary tasks of most developers is to paper over cross-browser issues it becomes in their best interest to see the number of bugs reduced (and making their job dramatically simpler).
I’ve personally filed bug reports with every major browser vendor and I’ve noted a couple characteristics that make for a good report.
How to File a Good Bug Report
The three points that make for a good bug report are: categorization, test case, and reduction. Any bug that is categorized correctly and provides a reduced test case is guaranteed to be reviewed by a browser developer.
Let’s start with where to file the bug itself.
Filing a Bug Report
Frequently when you go to file a bug report you have to wade a couple layers deep before you can get to the actual submission form. I’ve provided direct URLs to the best forms to use, below.
When you’re filing your bug be sure to also test it in the latest nightly of the browser you’re filing against (which I’ll describe later on). This will be one of the first things that a browser developer asks. If you can show that the bug still exists in the current development version of the browser, that it has not been fixed, then it’ll be that much easier for them to get started.
Note: Many of the bug report pages require that you create an account before submitting a report. This is an annoying one-time cost.
Categorizing the Bug
Categorizing a bug properly is an important first step. Frequently the owners of particular modules (such as layout or DOM) watch all new submissions that come in. Assigning a bug to the correct category will instantly put it before the eyes of the very person most capable of fixing the bug.
The categorization of a bug depends on the browser (some browsers, like Opera and Internet Explorer), provide simplified categories for filing a bug while others (WebKit/Safari and Mozilla/Firefox) use complex categories to denote the specific module where a piece of functionality might exist.
Mozilla/Firefox: Choose a Component. Some of the most common ones: DOM, Layout, JavaScript Engine.
WebKit/Safari: Choose a Component. Some of the most common ones: HTML DOM, Layout and Rendering, JavaScriptCore.
Google Chrome: Figuring out if you should file for Chrome is tricky. First test your bug in both the latest release of Safari and in the latest WebKit nightly. If the bug exists only in Chrome then file there, otherwise file the bug with WebKit/Safari. One problem, though: Bugs that only exist with the Chrome JavaScript engine (V8) should be filed in the V8 bug tracker instead of the Chrome one (lest it get lost in the shuffle).
Also, Chrome does not provide an explicit means of categorization. All bugs are reviewed by a developer and then categorized (you have no control over this process).
You should also take the quick step of testing on more than one platform (OS X and Windows, Windows and Linux, etc.). Simply determining that the bug exists on more than one platform can dramatically help to reduce the time needed to locate the cause of the bug by the browser developer.
Providing a Test Case
Any type of reproducible test case is better than nothing. A web page that’s able to encapsulate the problem is generally a good start. If the web page is able to be attached to the bug report directly, that’s even better (it may take a while for the browser developer to get around to your ticket and if your test case no longer exists at the URL that you specified then they’ll likely just close your ticket and move on).
That being said there is such a thing as a bad test case. The worst kind is something like: “I have a web site at http://example.com and it doesn’t work in browser X, please fix.” That will take someone a considerable amount of time to locate the exact reasons for failure and will likely push your bug much farther back on the queue.
The best kind of test case is one that provides a reduction.
Providing a Reduction
Providing a simple test case is absolutely the hardest and most frustrating part of creating a bug report – but it’s also the point that’ll make your report most likely to be noticed and fixed. Even for the most qualified developers it should take no more than 30 minutes to create a good-enough test case.
The process for creating one is simple: Take a page that has the bug in it and rip out anything that doesn’t affect the reproduction of the bug. This includes stylesheets, images, JavaScript files, JavaScript libraries, and HTML.
For example, a while back when I was running the Dromaeo test suite and I noticed that WebKit kept crashing when it hit a certain point. I began by ripping out tests, unnecessary HTML, CSS, and images. I eventually worked my way down to a single test: Splitting a string. I then worked to strip out as much of the test suite as possible so that there were no external dependencies required.
Note the final result:
var str = “”, ret, fn = [];
for ( var i = 0; i < 16384; i++ ) str += "a"; for ( var i = 16384; i <= 131072; i *= 2 ) (function(i){ fn.push(function(){ ret = str.split(""); }); str += str; })(); window.onload = function(){ setInterval(function(){ if ( fn.length ) fn.shift()(); }, 13); };[/js] What was left was about as simple as you could get while still having the crash occur. This is a good reduction. Based upon this reduction the reason for the problem was quickly identified and resolved just a couple weeks later.
Is my bug being worked on?
This is a challenging point – but one that’s easier to determine with Mozilla/Firefox, WebKit/Safari, and Chrome (since they’re all relatively open projects). Here’s the best way to determine the status of the bug with each of those browsers.
Mozilla/Firefox: Your bug will start out being assigned to the default contact for the component category that you originally selected. This doesn’t mean anything, yet, it’s simply attracting people in to look at your ticket. People will start to CC themselves in to the ticket (which means that they’re interested in its progress). The defining moment, though, is when someone assigns the bug to themselves, effectively stating that they are taking responsibility for the status of this bug. Most contributors have it set up so that any future comments on the bug are automatically emailed to them so if you have any questions about the status of the bug you can feel free to post a comment – but please do so at a reasonable pace (asking for daily, or even weekly, updates would be frustrating).
WebKit/Safari: WebKit uses a very similar setup to Mozilla/Firefox – just look for someone to take control of the bug and drive it to completion. The golden ticket, though, is when your bug “goes to rdar“. Radar is Apple’s internal (private) bug tracker. Having your bug move to there means that your bug is, effectively, guaranteed to be completed at some point (if not by the person who ‘owns’ it then by another Apple employee). Since Apple is still the major driving force behind WebKit updates having your bug move to rdar is what you should be hoping for. That being said, since rdar is private to Apple employees you no longer get the benefit of knowing if or when your bug will be completely fixed – it’s just a waiting game.
Chrome: Chrome uses a system very similar to Mozilla/Firefox. Be sure to keep up communication with whom the bug is currently assigned to and to answer any questions that they might have.
If your bug eventually gets resolved then congratulations! You just helped to make the web a better place for everyone.
But that’s not always the case.
What happens if my bug gets rejected?
Rejected bugs fall into two categories:
- It was rejected because it was not a bug.
- It was rejected because they browser vendor does not feel like working on it.
The first point is broken down into two further sub-categories:
It’s legitimately not a bug. Congratulations! You’ve learned something about a standard, or some other browser obscurity, that you weren’t familiar with: you’re now a better web developer! You should fire up your blog and write about the obscure new bug or API that you discovered and explain it to the world.
Or it is a bug and the owner unnecessarily closed it. At this point you need to argue your case to re-open it.
The second point (the vendor does not feel like working on it) is also handled in two ways:
First, argue your case for the bug. This should help inform the browser developer that they should dedicate valuable resources to fixing this issue.
Or second, if they are truly unwilling to fix the bug: Raise holy hell on your blog, Twitter account, and any other place where other web developers will listen to you. If you can’t find anyone else who agrees with your plight then you are probably crazy – but if it’s a legitimate problem that the browser vendor is refusing to fix then you should easily find others with whom you can band together and complain openly to. But that’s OK: You’ve earned this right. By doing all the due diligence necessary to bring this bug to light you earn full privileges of bitching about it in every other sentence.
Arguing a Bug
So you’re at the point where your bug has been closed and you need to convince the closer that this was a mistake – that what you have is an actual, legitimate, bug.
Here are some of the best arguments that you can use, in order of which they should be used:
- Show that the bug was a regression. Prove that it was something that worked in a previous release that stopped working because of a change. Works great in conjunction with #2.
- Show real-world web sites breaking. If you can show that actual users are going to no longer visit X bank in Poland or Y shopping site in Canada then browsers will easily bend over backwards to fix the issue (unless it’s Opera, in which case they may use their browser.js to force a site to work – but that’s another story).
- Show a web standard that is being violated by not fixing this bug. If you’re able to show that the W3C DOM specification is not implemented correctly because a certain bug is not fixed then a browser vendor should feel compelled to fix it. If not, this will make for great blog fodder.
- Show that not fixing the bug makes a browser incompatible with other browsers. If IE, Safari, and Opera all implement a specific feature or fix a specific bug then Firefox should be compelled to comply with the other implementations (as long as its not in contradiction with a specification). This is the hardest one to argue – but it becomes easier the more browsers that are on board.
If you can’t prove any of those steps then you’re probably just scratching your own itch anyway – and should lay off.
Examples
I want to show some representative examples of bugs that I’ve filed with different browser vendors.
WebKit/Safari
Canvas arc() with radius of 0 throws exception: Calling the Canvas arc() method was throwing an exception. I provided a super-simple test case and pointed to the specification that they were in disagreement with. Was resolved the same day it was posted.
Out of Memory Error with .split(“”) due to large number of live objects: Provided a simple reduction with hosted web page, was fixed about 3 weeks later.
Mozilla/Firefox
Huge Speed Drop in Array.prototype.sort: Showed a regression with a simple reduction. Included a bunch of very-useful Shark profiling data to help pinpoint the exact issue. Was fixed within a month.
Implement .children: Argued that Mozilla needed to implement the .children method (which was in every other major browser). A good debate led to its eventual inclusion (about 6 months later).
Internet Explorer 8
querySelectorAll NodeList Exception: Provided simple test case, was rejected due to ‘lack of time’:
At this time we do not plan on fixing this issue. We appreciate the report, but unfortunately we are at a stage where need to choose what we work on to maximize the value for customers and web developers.
So while they agree that it is an issue – they do not plan on fixing it. That means that I now get to complain about it!
HTMLElement.prototype.querySelectorAll doesn’t exist: As it turns out this was because querySelectorAll only exists in standards-compliant pages (not in quirksmode). This is positively bizarre but I think I understand their rationale behind the decision. I suspect that this will bite a lot of people once IE 8 goes live, we’ll see. I now know more about IE8 and am a better developer for it.
Google Chrome
for in loops don’t occur in defined order: This was a compatibility issue (all other browsers behaved in a particular manner). I provided a simple test case. It was accidentally closed as WontFix (which caused confusion) but was actually fixed. I made a mistake here and actually filed this bug against Chrome when it should’ve been against V8 – here’s the bug that dealt with the issue over there.
setTimeout(…, 0) fires too quickly: This was actually due to a structural change made by the Chrome team. Mike Belshe (the author of the change) personally emailed me to explain what happened. I became much more informed as a result and blogged about it.
Opera
(Opera does not provide an official public view for bug reports, that I know of.)
How to Test a Nightly Build
Before we get into the details of testing a nightly build of a browser I should probably answer the most common question: Why should I care about testing a nightly build of a browser? There are a couple reasons.
First, when filing a bug report you’re going to need to determine if the bug you’re submitting has already been fixed, or not. If it’s already been fixed in a nightly then you don’t need to worry about submitting it – the bug will be fixed in the next release. If the bug has not been resolved, though, then you should be sure to continue filing the bug.
Second, you should periodically test your site or library in the latest browser nightlies – to make sure that your code isn’t going to break when the browser is released. How often you test is up to you – but the more frequently you test the more likely it is that your site or library won’t hit a massive regression at some point. I think it’s pretty safe to say that no developer likes finding out that there’s a new browser version on the market that breaks their site.
Filing a bug for a nightly is just like filing any other bug. Provide a reduced test case and be sure to emphasize that a regression occurred. If you’re testing frequently enough this should be sure to get the developers hopping into action.
Getting the Latest Nightly
Browser vendors provide a variety of techniques for getting the latest version of a browser. Some browsers release more frequently than others, as well (for example, Chrome updates multiple times a day, Firefox once a day, and Opera every couple weeks or so).
Mozilla/Firefox
Mozilla provides nightly releases of Firefox. It can be installed, and used, alongside your existing copy of Firefox using Firefox Profiles. Once you download one nightly release it should update itself, automatically, every day.
Download: Firefox Nightly Release
WebKit/Safari
WebKit nightlies are easy to install on OS X – they can live completely side-by-side with no profile details. However they do not update automatically. I use NightShift to make sure that my WebKit nightly is kept up to date (on OS X).
Doing a nightly install on Windows is much more cumbersome (it involves running some scripts and copying files around) but it works.
Download: WebKit/Safari Nightly Release
Internet Explorer
Internet Explorer installs are “a big deal” – they completely blow away any previously-installed copy of the browser. For this reason you should be sure to use some tricks to keep multiple copies of Internet Explorer installed on your system. There’s one installer that can handle IE 6 (and older) and another one for taking care of IE 7. Once you have all those standalone versions installed you can feel safe downloading and installing IE 8.
IE 8 automatically updated from each beta release but it doesn’t appear to do it any more. If you sign up for the Microsoft IE Beta Connect program you can get more recent builds to test against. Again, all of these builds will overwrite older versions of the current browser.
Download: IE 8 Betas, IE 8 Weekly Builds
Google Chrome
Google provides multiple builds per day (one for each revision). These builds can live side-by-side with one another but they do not update automatically. One user built an automatic update application that you can use to make that happen.
Download: Google Chrome Nightly Builds
Opera
Multiple versions of Opera can be installed side-by-side and they update automatically. They don’t provide nightly builds (they come out every couple weeks, or so) but they should serve as a relatively-current example of the browser.
Download: Opera Desktop Team Blog (builds are posted here)
The importance of taking an active role in the future of web development cannot be overstated. Shifting from a passive position of hoping that other developers will be proactive about filing bugs or hoping that browser vendors will notice every possible regression to one of active diligence gives you an incredible amount of power. The minimal amount of work that you do to improve communication between the web community and browsers does volumes for helping to improve the quality of the entire web.
You should wear every bug that has gotten fixed, because of you, as a badge of honor: You’ve done your part to make the web a better place.
Burin (December 29, 2008 at 6:29 pm)
great write up john :)
I’ll have to honestly admit that I forget that there are people who fix browser bugs :x This was a good reminder that things are moving forward and complaints aren’t falling on deaf ears
I’ll definitely report any bugs I come across!
Michael Jackson (December 29, 2008 at 6:36 pm)
Excellent resource John. Thanks for putting all this information in one place.
Andrew Hedges (December 29, 2008 at 6:43 pm)
This is great, John, thanks. I have actually filed a couple of bugs against WebKit, mostly from bugs I discovered working on Dashboard widgets. I admit, tho’, to being pretty lax about it. Think of where browsers might be today if we’d all been actively doing this for the last 10 years! So, let’s all active do this and 10 years from now celebrate the excellent state of browsers! :-)
mikeal (December 29, 2008 at 7:21 pm)
While I think the principal here is correct “Web Developers should take responsibility for reporting issues with browsers to vendors” I think you’re missing another huge issue that vendors rarely take enough responsibility for.
Vendors should be responsible for reducing all the barriers to filing/finding issues with their browsers.
Searching for existing issues varies in difficulty between vendors. The more difficult it is to find out if an issue is already filed the greater the tendency to just say “oh, I bet they already know about this”.
In general, the tools that browser developers use to track issues seem to follow the workflows of browser developers and not web developers or browser users. From the outside using these tools can be rather opaque to people who don’t develop these specific browsers. Even browser developers tend to find it difficult to report issues against browsers they don’t work on.
I don’t think brow beating a community to participate more in something that clearly will benefit them is an effective way to increase participation. And I don’t think it’s an “education” problem the same way bad UI isn’t an issue of just educating users.
A much more effective way to increase participation is to remove barriers to contribution of which all the vendors have many. This has been outlined by everyone I’ve ever heard speak about building community and if you look at the community driven software projects that don’t have large institutional backing you find they are much more attuned to this issue.
John Resig (December 29, 2008 at 7:37 pm)
@mikeal: I absolutely agree the browsers should do more to remove barriers – but there’s a big difference between wanting more bug reports and better quality bug reports. Even with all the incredible barriers that Mozilla’s Bugzilla installation puts forward, obscuring the final goal of a bug submission from the user, they already receive many, many, more bug reports than they can effectively deal with (and simply marking a bug as “confirmed” is not “dealt with”).
As it stands I don’t think Web Developers (collectively) know why or where they should submit bug reports – and even if they do – what it means to submit a bug report. We have to work to get over those barriers first before we can tackle making it easier for users to submit bug reports. I think any browser vendor would agree (and, from my experience with the jQuery project, I would agree too) that I would prefer 1/10th the bug reports if each report was 10x better. With jQuery the vast majority of bug submissions are completely non-issues and are the user’s fault to begin with – and I’m sure this is the case with browsers, as well.
Note that I never mentioned searching for existing issues in my write-up. To a web developer (and, really, to a browser developer) this doesn’t matter. All that matters is that there is a good reduction to something that is obviously unresolved. Having a duplicate chunk of data representing a bug report is a non-issue – I really think that web developers shouldn’t concern themselves with it.
I want to emphasize that there exists no magical UI improvement that will make nightly browser testing trivial nor does there exist a “perfect” bug tracker that is capable of creating a reduced test case. These are things that must be done by the developer. It’s hard work and they don’t do it nearly enough. Considering that the collective input of the web development community is bordering on 0 to 1% some solid “brow beating” is absolutely in order.
I just want to reiterate that browsers can and should do more – it’s in their best interest to do so. But they already do a lot (checking hundreds of thousands of web pages for errors and regressions) compared to the relatively little input that the web development community gives as a whole. If every web developer filed a bug every time they found a bug the state of web development would’ve been advanced by a decade, at least.
kangax (December 29, 2008 at 7:44 pm)
John, I get “The content that you requested cannot be found or you do not have permission to view it.” when following an IE8 “file a bug” link. This only happens after signing in (when signed out, it obviously presents a login form).
Have you stumbled upon anything like this?
John Resig (December 29, 2008 at 7:50 pm)
@kangax: It appears as if what I linked to was a temporary URL, this appears to be the correct one:
https://connect.microsoft.com/IE/Feedback
mikeal (December 29, 2008 at 7:58 pm)
@john Good point, quality is a big issue. But I still disagree that poor bug discoverability isn’t a part of the problem.
For instance, most of those cases where people log a bug for a non-issue happen for the same issues over and over again. If the google search they did before logging the bug uncovered an old bug filed that was market NOT A BUG and explained the issue, they never would have logged it again.
And sure, valid duplicates aren’t much of an issue. But invalid duplicates or duplicates that lack so much in quality that time is spent figuring out what the real issue is wouldn’t be logged if bugs were found via easily via Google, which is the first instinctive thing people do when they have an issue.
Your point about web developers not knowing why/where they should log a bug and your comment about brow beating are well taken. My exposure to the development community in general is very skewed towards open source developers so my perception is different and less accurate than yours about awareness of web developers in general.
In any case, I think it would be effective for vendors to start putting more time in to reducing barriers to non-code contributions. Oh hey, look at that http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/ :)
John Resig (December 29, 2008 at 8:05 pm)
@mikeal: I, also, got super-excited by Aza’s post. I can’t wait until there’s a huge UI overhaul of Bugzilla. There needs to be two UIs: One that’s user-centric and one that’s developer-centric – and never the two shall mix.
You know, that’d make for a really interesting resource: Take the most commonly NOT A BUG bugs and turn it into a book/blog/etc. – something like “browsersareweird.com” that just goes through these issues. In fact, I really like that idea – I just bought browsersareweird.com :)
mikeal (December 29, 2008 at 8:10 pm)
@john Multiple UIs, EXACTLY!
browsersareweird.com could even have pictures the users submit with lolcat-esque comments attached.
ME NO W3RKZ MOUZEZ RIGHT
Ok, that might be a little mean :)
Brian Slesinsky (December 29, 2008 at 8:14 pm)
Assuming existing technology and existing levels of education, you can’t expect 10x the number of good bug reports without also getting 10x the number of bad bug reports, and the ratios may very well get worse as you include more casual web developers in the mix.
But why should noisy data be a problem? Search engines don’t die when you give them more data, they get better. The same would be true of bug reporting systems if they were designed properly. Sending a bug report should be as easy as sending a crash report, and the interaction should be about the same.
There’s also the problem that the social expectations are wrong. When someone reports a bug, they’re *giving you a gift* and you can do what you please with it. Keep it, throw it away, whatever. There should be no obligation for followup on either side, any more than with a crash report.
What we really don’t need is lots of pushback saying “you’re not sending bug reports properly” being being sent to people who are *already doing us a favor* by responding at all. That just results in more people deciding it’s not worth the hassle and less data.
Rijk (December 29, 2008 at 8:37 pm)
Good writeup, John. For those interested, here are some excellent write-ups on making good test cases for browsers:
http://hixie.ch/advocacy/writing-test-cases-for-web-browsers
http://www.w3.org/Style/CSS/Test/guidelines.html
The idea is that a test case is simple enough if anyone can see at a glance whether a test case is PASS or FAIL in a browser.
John Resig (December 29, 2008 at 8:37 pm)
@Brian Slesinsky: The fundamental difference between crash report and search engines compared to “bug reports” as we know them is that they refer to very complex operations that aren’t easy to quantify. There’s simply no way to send an automated report when a web page “looks weird” – there has to be humans on either end who are both willing to help each other in order for the process to move along.
I feel that it’s the attitude that you promote here that is such a disservice for the web development community as a whole: Web developers shouldn’t be bothered with helping browsers and if they do it should involve no interaction on their part, their trite bugs are gifts to the browsers themselves! That’s insane. No one should feel as if the other party has a greater responsibility. It’s up to everyone to work as hard as they can to make the web better – promoting lackadaisical input by web developers is a huge mistake.
Web developers (and even casual ones) are much more qualified to determine why a page is working incorrectly. By taking a small step forwards a developer can do so much more than push a trivial “this page is broken” message the browser’s way. That’s something that a normal user can do – web developers have the responsibility of doing more to help find and diagnose bugs. Since we’re all part of the same ecosystem (web sites, web developers, and browsers) we all have an equal responsibility when it comes to pushing the web forward.
Brian Slesinsky (December 29, 2008 at 10:27 pm)
I don’t agree that “we all have an equal responsibility when it comes to pushing the web forward.” The whole point of volunteering is that you have as much or as little responsibility as you choose to take on; that’s what volunteer means. And the best way to get more volunteers is to make it easier to contribute tiny amounts of work; this is one of the lessons of Wikipedia where you can contribute a one-character spelling fix.
The reporting side could be a lot simpler than you think. How about a plugin adding a button to take a screenshot of a page, with a way to highlight the error and capture the original HTML and linked files? That results in a reproducible test case and it shouldn’t be any harder than crash reporting.
Granted, interpreting the data is harder. Perhaps there could be some kind of “bisect” tool to remove parts of the page and see whether the bug is still there, and this could be done by anyone, before or after the bug is reported.
Alex (December 29, 2008 at 10:59 pm)
I’ve got 2 systems running 2 different versions of Firefox, which is a great way to track differences and bugs.
Last night I drew up an SVG image in Inkscape that renders completely wrong in Firefox 3, parts are offset, stuff is cropped out, etc., tested it in 3.1 and it renders perfectly fine.
Funnily enough, most of the bugs I’ve found in browsers seem to be SVG related, found a crasher in WebKit, a problem with filter corruption and a problem with SVG files using embedded fonts in Firefox. The worst bugs are the unreproducible bugs, especially if they’re bad crashers.
Greg (December 30, 2008 at 12:01 am)
Good post and thanks for filing those bugs! I’ve nievely thought that sites like quirksmode.com and acidtest 2/3 have a good handle on this. I’ll aim to do more in 2009.
Does the world have a cross browser unit test suite for these reductions? Seems that each of these would be useful for all browser developers and perhaps web developers as well.
Oliver (December 30, 2008 at 12:47 am)
@Alex: did you report the bugs?
Shwetank (December 30, 2008 at 1:13 am)
@Brian: Doing what you suggested would raise privacy concerns.
@John: Excellent post. I really hope more web developers start to file more bug reports, and I can say from personal experience that web developers are far more qualified to provide a detailed and thorough bug report, which in the end increases the likelihood of the bug getting fixed faster. (Since developers are more technical, they generally have a lower chance of filing an invalid or even duplicate bug report).
Having said that, I would encourage everyone, not just web developers, to go ahead and file a bug report. We can’t expect non-technical users to file test cases, but certainly any help to make browser makers aware of a particular problem would be greatly appreciated.
Ken (December 30, 2008 at 2:22 am)
You make some good points, but I’m going to play devil’s advocate:
– Running nightlies can be a pain. Filing bug reports is usually a pain. Nursing your bug is a pain. Reporting bugs has a real non-zero cost.
– There are plenty of 5-year-old bugs that still hurt me far more than any new ones I find. (I’ve filed many, many bugs against browsers, mostly Firefox. In almost all cases, it’s duped to some ancient bug that nobody seems to both care about and have the knowledge to fix.)
– It depends entirely on your audience, but if you’re one of us who’s testing against IE6 (because that’s what our customer$ use), it doesn’t even matter if your site looks like barf in Firefox 3.x, because our customers won’t be using it — at least, not within 5 years.
– None of this matters to many of us anyway, because if you are really anal about compatibility then you’re going to spend 95% of your time fighting IE6/IE7 bugs, and they simply can’t be fixed and won’t be upgraded beyond.
The problem isn’t that new versions of browsers have bugs. It’s that old versions of browsers do. IE8 and FF3.1 could be 100% bug-free and it wouldn’t make a lick of difference to my job (and to a first approximation, they are).
I wonder if I could found a company based on the premise “fuck legacy browsers”. I’m sure I personally could be far more than 2x as productive if I only had to run on FF3 and Sf3.
Shwetank (December 30, 2008 at 2:59 am)
@Ken: I guess the point of the post is, that in the long term, web developers and browser makers have to to work together to make sure sites are compatible with browsers. One of the most important ways to work together, is to make sure developers report bugs and browser makers fix them.
For every old bug which hasn’t been fixed, there might be an old problem which wasn’t brought to the attention of the browser makers in the first place, simply because a developer thought that developing only with IE6 in mind is the only thing they’ll do.
Also, as time goes on, share of IE6 will drop down. It always has been the case that legacy browsers have dwindled. If people don’t report bugs, then developers might have the same problems with IE8 in the future that they face with IE6 right now.
Also, I’m sure that developers will be a 1000% more productive if there was just one browser in the world to code to, but would users really want that? The best bet is still for developers to follow standards, and for browser makers to implement support for them to the maximum possible extent.
Also, I guess the ‘pain’ of downloading and installing the nightly/weekly builds is less than finding out that suddenly your sites break in the new version of a browser. Even if you don’t download nightlies, at least developers should play around with the alphas and betas, whenever they are released.
Adam Hooper (December 30, 2008 at 3:12 am)
Ditto what Ken mentioned: for a busy web developer, filing bug reports does absolutely nothing to make progress on deadlines: not only does it produce more future work (following up on the bug report), but it changes nothing in the final product because the workaround must be implemented and maintaned practically forever.
Filing bugs on nightlies makes sense, sure: if I find a bug and nip it in the bud, I will never have to work around it. But there is no positive outcome in my filing bug reports for IE5, IE6 or IE7 (and I have tried)–and those are far and away the buggiest browsers out there.
From a product management perspective, there is zero return on investment for filing bugs on released, supported browser versions. I appreciate the utopic notion of people filing bugs as they find them: it hearkens to open-source-community hyper-neighbourly etiquette. But as with open-source projects, bug reporting is destined purely for testers and enthusiasts (where the degree of “enthusiasm” depends on the painfulness of the bug-reporting process).
If browser developers solve *that* catch-22, I’ll happily and productively file bug reports all day.
Xificurk (December 30, 2008 at 4:05 am)
Thanks for the article, when I started reading I was hoping I’ll finally find out how to file an IE bug report… Not long ago I have discovered bug in IE7+ and spent two hours by googling only to sadly realize – I really can’t find the way. I did get to the URL you provided in this article but I fail to see a “report bug” link, the best I could do was to start a thread in their newsgroup, as MS advice…
“If you have an issue with the IE8 beta that is not reported, we encourage you to visit the “IE Beta Newsgroup”:[http://go.microsoft.com/fwlink/?LinkId=110585]. Members of the Technical Beta program can verify and submit bugs on your behalf.”
Any hint you could provide on the subject “How can an ordinary web developer file a bug report to MS.” would be very appriciated.
Joe Chung (December 30, 2008 at 7:12 am)
The problem with this post is that the two browsers with the largest marketshare aren’t being maintained: IE 6 and IE 7. It’s great advice for the rest of the browsers though.
Seamus (December 30, 2008 at 8:23 am)
Thank you for the reporting to IE. I could not find it to report a CSS bug in IE8 and was about to give up on trying to directly telling them about it.
Really good tips all and all for on how to report a bug.
John Resig (December 30, 2008 at 9:05 am)
@Ken, Adam Hooper: I absolutely agree that it’s hard and frustrating – I even stated so in the article. But if you want a really binary way of looking at it: Either you’re helping browsers to improve, or you’re not. I argue that we’re all in this together, browsers and developers. We both have a responsibility to try and improve the quality of the browsing experience. I agree that this isn’t something that clients ask for – just as it is that clients don’t ask you to contribute to Open Source projects – but it’s something that good, discerning, web developers can do to go above and beyond the normal development routine.
@Xificurk, Seamus: I absolutely agree that Internet Explorer’s bug submission process is abysmal. No way to submit bugs for old browsers and the only way you can submit bugs for IE8 is if you get a special invitation code. Horrible. It just figures that the browser with the most bugs is least receptive to finding out about how to fix them.
Timothy (December 30, 2008 at 9:20 am)
I have to say, I am one of those designers you speak of that has never filed a bug report. But now maybe I will. Just maybe.
I think this comes down to simple economics. Filing a bug report takes time out of my day. It is time that I can use doing something else. If filing the report is my best option than I will file it, 100% guaranteed. But, if anything else, anything at all, seems like a better option at the time then there is no reason for me to file a report.
For example, if I am working on a project and am just about done when I come across a bug, filing the bug means that my project time is extended. And, often near the end of a project you really look forward to completing it and having the final product (which always fells pretty good). So, if finishing the project in less time by not filing a report gives me more utility then there is little chance I will file the report. Unless if I am not a rational being. But I am. Just like the majority of people.
It’s all about what you are willing and able to do. You are always able to file these reports. But the willingness is difficult. Maybe I wouldn’t mind filing a report, but when compared to other activities it is usually not the better option. Whenever you do anything, anything at all, you did it because there is nothing better to do.
Why did I write this comment? Because there is nothing better to do.
So, I may be encouraged by your post to file a report here and there, but probably not. There needs to be a bit more of an incentive, don’t you agree?
Robert S. Robbins (December 30, 2008 at 10:04 am)
I reported a “billion laughs attack” vulnerability in Opera quite some time ago and they still have not fixed it. The problem is that Opera will attempt to process a recursive entity reference in a SVG image file, a type of XML file, so you can consume memory with a malicious image file. The other browsers that support SVG detect this and display warnings.
John Resig (December 30, 2008 at 10:09 am)
@Robert S. Robbins: I don’t like the fact that Opera’s bug system isn’t open – there’s no responsibility incentive for them to finish up the bug in a timely manner. This sounds like a serious issue, though – one that could be used maliciously by hackers. If they’re not moving then you should publicly announce the problem – I bet they’ll go quickly after that!
Jason Kuhn (December 30, 2008 at 10:51 am)
@John Resig: Another good all-in-one IE tool is called IE Tester. It houses all instances of IE from 5.5 to 8b2 (if you have IE7 installed) in one window.
Multiple IE is cool, but there really isn’t any need to test in versions before 6. Although looking at some websites in IE3 is great for nostalgia.
Great write up!
RichB (December 30, 2008 at 11:28 am)
John, I hope you don’t mind me suggesting an improvement to your bug reporting style?
Despite our best intentions, URL are not always permanent. Some bugs (Gecko especially!) have been around for 5 or 6 years without being fixed, and URLs are rarely permanent for that long – resulting in a bug with just a URL for reference being difficult to understand. Therefore, a bug report should contain more than just a URL and the Outcome/Expected Outcome – it should also contain sample code.
For example, your IE8 report which was postponed by Microsoft may ultimately not get fixed in IE9 because your reference URL may change in the x years between IE releases….
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=388477
Jayakrishnan G (December 30, 2008 at 11:29 am)
I’ve filed an issue in bugzilla which is related to slow performance of js in FF3 when compared to FF2. The bugzilla team also acknowledged that it as a regression. But, till now they haven’t responded well (i.e., there is no response about whether the bug is considered and/or taken for fixing the same).
The issue can be viewed here…
https://bugzilla.mozilla.org/show_bug.cgi?id=470532
Can you advise me what to do on such a situation?
John Resig (December 30, 2008 at 12:04 pm)
@RichB: I think you may have missed the part of my blog post: “If the web page is able to be attached to the bug report directly, that’s even better (it may take a while for the browser developer to get around to your ticket and if your test case no longer exists at the URL that you specified then they’ll likely just close your ticket and move on).”
In the case of IE 8 they don’t provide a way to attach files to a ticket (neither does Chrome) so a URL has to do. As you can see in the Mozilla and WebKit bugs I filed I provided attachments and/or inline code examples.
@Jayakrishnan: You need to simplify your bug even more. Rather than asking the reviewer to load a web page and move the mouse around you should be able to show them definitive numbers. For example – “When I run this function it takes 40ms in Firefox 2 and 80ms in Firefox 3.” That’s something that developers can easily grasp and work with – something nebulous like “it feels slower” isn’t well defined.
Bob Aman (December 30, 2008 at 1:05 pm)
I filed a bug with FireFox a month ago, and as far as I can tell, nobody’s even looked at it. Which is a shame, because it’s a pretty simple bug to fix.
https://bugzilla.mozilla.org/show_bug.cgi?id=467563
Both Safari and Google Chrome exhibit similar issues, though Safari is really just a matter of providing a human-readable error message.
SeanJA (December 30, 2008 at 1:07 pm)
Doesn’t installing multiple IE’s mean that all versions of IE will use the same rendering engine (the one of the latest version of IE on the machine)?
Most of the Help->About Internet Explorer menus say “Version 7.0….”.
Doesn’t that defeat the point of having more than one version of IE if they all use the same rendering engine?
John Resig (December 30, 2008 at 3:59 pm)
@Bob Aman: That’s a big reason why categorization matters so much – if I had to guess I’d say that you’d get a better response if you filed it in Product: Core, Component: Networking.
@SeanJA: No, the reason for using the multiple IE is that it uses the different rendering engines. Depending on the style of Mutiple IE that you use the outer layer of the browser may stay the same but the internal rendering frame will be different. However, the one that I use serves it completely differently and as a separate browser (IE 6 is obviously different from IE 7 which is obviously different from IE 8).
Dan Fabulich (December 30, 2008 at 5:16 pm)
I can’t decide whether to laugh or cry at this post. At any rate, ordinary web developers like us should absolutely not follow John’s advice to file bugs and argue for them.
Browser vendors ROUTINELY ignore bug reports from web developers. Mozilla is bad, but Microsoft is worse. That’s because they are constantly inundated with crap bugs from ordinary web developers; the browser vendors are (above all) drowning in advocacy.
As a result, the only bugs that get attention are bugs from people who are known to be trusted. People like John Resig file bugs and developers respond. That’s not what happens when people like you and me file bugs.
Above all, arguing for bugs will NOT help… please save your time and browser developers’ time and DON’T argue for bugs, even if your arguments are good. The Mozilla bug DB is full of 5-year-old bugs with dozens of advocacy comments. The advocacy comments are met with derisive anti-comments: “Bugzilla is not for advocacy,” the developers reply. And the developers are right!
If you want to do any good, the only way to do it is to get TRUSTED. Specifically, if you want your bug reports to be respected, you need to do a lot of grunt work. For example, start by hanging out on Mozilla’s #qa chat room on Tuesdays. Anyone who hangs out there can be given QA assignments; if you follow directions for a few months you’ll eventually become a respected QA engineer. Developers will start listening to you when you file bugs, and you’ll get the Bugzilla right to mark bugs as “CONFIRMED”, target them for particular milestones, and so on.
And for Microsoft? Get to know the folks who work there. Offline. Really, the best way to get them to listen to you is to increase your influence and standing in the community… to become John Resig!
If you don’t have time with this? That’s OK, it’s really NOT your responsibility. You can save everybody a headache if you just don’t bother. :-(
What’s so tragicomic about this post is that John, who is already trusted, has no idea what it’s like to file a bug report when you’re not John.
John is “surprised” that we don’t bother filing bugs because whenever HE files bugs, people fix them. Ordinary web developers don’t bother filing bugs because our feedback is (rightly!) ignored.
PS The point of Aza’s social networking enhancements in Bugzilla is just to automate this process of ignoring untrusted individuals. Unfortunately, that’s absolutely the right thing to do! :-(
John Resig (December 30, 2008 at 6:40 pm)
@Dan Fabulich: You’re grossly misconceived as to what weight I have (if any) when filing a bug – or even, really, my history of filing bugs and my history as a developer. I’ve had bugs rejected from every browser vendor – in fact I would say that the majority of my bugs have either been rejected or are in limbo. For example, according to you, I should be able to get all my bugs approved and fixed by Mozilla – since I work for them. Right now my current stats are (discounting the bugs that I created and fixed myself): 10 unlooked at, 1 assigned, 4 fixed, 3 duplicates, 2 invalid, 3 worksforme.
Not a very good batting ratio. However, amongst all the bugs that have been fixed, or otherwise resolved, they all follow the guidelines that I outline above – whereas most of the other bugs I’ve filed are more nebulous or harder to justify.
“has no idea what it’s like to file a bug report when you’re not John”
Well, no, but I do know what it’s like to read bug reports – and I can tell you that any bug that is capable of following every point that I outline above is far, far, more likely to get noticed and resolved. I’ve read thousands of bug reports both at Mozilla and in my work on jQuery and these guidelines will be certain to help anyone filing a bug in any project.
The reason why most bug reports are ignored isn’t because they’re written by the “unwashed” it’s because they’re bad bug reports. File good reports and they’ll get looked at – I can guarantee it.
Don’t you think there could possibly be a correlation between people who are noticed and trusted and people who are skilled developers, capable of filing a good bug report? Absolutely no one is able to use their ‘trust’ alone to push a bug through. It requires hard work, good tests, and solid arguments. Nothing else.
Mark Rowe (December 30, 2008 at 7:00 pm)
> The golden ticket, though, is when your bug “goes to rdar”. rdar is Apple’s internal (private) bug tracker.
*Radar* is Apple’s internal bug tracking system. rdar:// is the protocol that happens to be used for URLs into that system.
Damian Shaw (December 30, 2008 at 10:02 pm)
@Dan Fabulich: I have to disagree, I’ve been seriously using Bugzilla for about a year now and have found this method to be very effective. I’m not a web developer so my bugs aren’t always so simple to reduce down to a simple test case, but I’ve been able to get bug re-opened by simply more clearly stating my case.
I’ve also found that at times Mozilla staff get less attention than me, I’ve seen Asa file bugs that have not been picked up at all. Also at times I’ve felt I’ve made better cases on some bugs than a Mozilla employee and my arguments have sometimes eventually prevailed.
I would totally suggest arguing for a bug as long as you feel it’s a real issue, you’ve got either a very high quality thought through argument that you can present simply and clearly or you’ve got real world evidence of it being a problem.
V1 (December 31, 2008 at 6:11 am)
I think its also hard to identify what is actually a bug or just a piece of sucky code, miss understanding of the functions or just a good workaround.
For example, today I worked a bit on my dom ready functionality, originally i started it as tweak for IE’s doc write dom ready functionality but it was slower, but when i tested my code in firefox and opera it was actually faster than the native functionality that is supplied by the browsers (DOMContentLoaded). My script is about 30 ms avg faster in firefox than the DOMContentLoaded.
Would that count as a bug because you would expect that a native piece of code is faster than a bit of custom javascript, but the piece of code does not really stand in relation to the native piece of code..
I always find it hard choose to report it or not..
btruelove (December 31, 2008 at 6:27 pm)
by submiting bug reports for a piece of software you are improving or adding value to that software. when doing this you might want to first consider if this is in your best interest.
many web developers realize that IE’s goals are not to the benefit of the web at large. in many cases they are holding back web developers and the state of the web browsing experience.
is this something you want to actively support, for free, on your own time by submiting bug reports for propriety software like IE?
mm (December 31, 2008 at 8:22 pm)
Here is a bug, view this in IE8 beta…
Blank
#foo, #bar { position: absolute; }
foo
bar
you wont see anything (at all) unless you make at least one of the positioned elements block-level. IE8 refuses to display any part of entire web pages if this occurs anywhere on your page.
I’d report it, but I can’t access their feedback section either!
Ben Hollis (December 31, 2008 at 11:01 pm)
Thanks for the writeup – it’s inspired me to finish up some repro’s I had lying around.
It’s frustrating though that the browser with the most market share also has the worst bug tracker, no feedback on the bug resolution, and is most likely to close real bugs as WONTFIX. Add in the fact that Microsoft hasn’t done a great job of getting people off of old versions of IE and you’ve got bugs that are 8 years old that will not be fixed in a browser almost a fifth of your visitors will be using, with no way for us to help. So I feel a *little* justified complaining anyway. ;-) Really the best we can do with IE is to write up any bugs we find publicly so that some frustrated programmer will be able to find a workaround somewhere.
I applied for the feedback ability in Connect but I still can’t file bugs. Oh well…
Boris (January 1, 2009 at 2:28 pm)
> Perhaps there could be some kind of “bisect” tool to remove parts of
> the page and see whether the bug is still there
Jesse Ruderman has such a tool; he uses it to reduce his randomly-generated fuzz-tester testcases.
But in general, a bug with a better report (in the sense of http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) will just get prioritized over a worse bug report, since that’s the smart resource-allocation decision. So if you really want the bug fixed…
Wedge (January 6, 2009 at 1:57 am)
To all those who are so selfish they can’t see how improving web development for everyone is in every web developer’s best interests I offer an example of how filing browser bugs will help even the most selfish individuals: your resume / job prospects. If you have a history of filing high quality browser bugs, especially if those bugs are important enough and have good enough descriptions to get fixed, that can go a long way toward distinguishing you from the rather substantial pack of otherwise seemingly equivalently skilled web devs in the industry. And that can in turn result in an easier time getting better, higher paying jobs, which means more rewarding work and more cash in your pocket, and who doesn’t want that?
Simon (January 6, 2009 at 2:01 am)
John,
Love your work… but I am confused first by your terms… “browsers and developers”
I am a developer of websites not a developer of browsers… ie, a browser, not a developer of “browsers”. My expertise lies in developing a platform for my clients to view their websites… and to handle their development issues… do you see where I am going. To an extreme I would be “bug fixing” rendering engines not scripting or code issues. I agree with Dan Fabulich in that we all have our ‘core’ dependencies… though my view is that if I am returning to my client for error checking and bug reports, it comes down to one of two things… either the brief was incomplete or we are managing badly and gaining not traction, but creep.
I would love to able to get bug reports off… though my marketing background is overflowing with XML (5yrs on); PHP, SQL, javascript, your amazing jquery, I could say Flash (though it was never my bag)), CSS (still!!) and now XCode and several other minor client specific requests like .net and ASP (hmmmm)
Ohh… and as an aside, I do recommend to all my clients that WE develop for Firefox alone. Sorry this is such a disjointed post… clients can be demanding (IE6 demanding (( ). A tool set for de-bugging would indeed be heaven :D
Lea Verou (January 7, 2009 at 5:34 pm)
I filed my first bug today (border-radius is ignored when border-image is set in FF3.1b2) and it got a response just a few minutes later! Wow!
Jayakrishnan (January 9, 2009 at 5:17 am)
@John Resig: The user experience itself explains the bug very well! And, i believe the regression’s nature (i.e., very sluggish with empirical evidence) is in such a way that there is a need to mention the difference of speed in milliseconds thus complicating more. Anyways, its the developers call!
Jayakrishnan (January 9, 2009 at 11:44 am)
@John Resig: I made a typo in the comment. What i intended to say is that there is NO need to mention the difference of speed in any units!
Spartacus (January 12, 2009 at 11:37 am)
Here is a related article on testing your web pages in multiple Internet Explorer versions.
Mark C (January 14, 2009 at 1:51 pm)
Of the few bugs I’ve submitted, this one has taken the longest and gotten the least attention (but was probably the most important bug I’ve found):
https://bugzilla.mozilla.org/show_bug.cgi?id=427042
9 months later and nothing to be found in terms of actual speculation.
mrf (January 15, 2009 at 3:01 pm)
Just wanted to give a heads up to other readers on something that confused me a bit.
When you download the nightly for Firefox the application package is called Minefield rather than Firefox.
Once I realized I had indeed downloaded the Firefox nightly and not some new version of minesweeper, setting up a new profile for minefield went smoothly using the instructions from the link above.
Having a separate name is actually ends up being nice because now I easily know exactly which version I’m opening with Quicksilver.
paulhan (January 17, 2009 at 8:59 pm)
Hi John,
This is probably my first negative posting, in the sense that it is contrary to the author’s contention.
I think most serious web developers (in the context of the open web) now use a library to abstract out the very bugs that you are saying we should complain about, be it the most excellent JQuery, Prototype, Mootools, YUI, whatever.
If someone from one of those frameworks files a bug report, it behoves the browser vendor to take more notice of the bug, or else risk losing market share, or support from the framework. Also, there is more likelihood of the framework authors meeting the browser vendors at various conventions etc. For those reasons, these types of reports will get more attention.
What I’d like to see is a voting system, whereby framework vendors file a bug, and then ask their users to vote up that bug. Browser vendors would then see that a particular bug is important to developers (framework and/or web) and allocate resources to fix it. Asking web devs to negotiate all the different ways of filing reports and then following up on them is a lot to ask, given that most of us need to pull together five languages and at least one framework, plus server, testing, analytics, ad optimisation and SEO stuff, in order to get a site/app up. I think you’d get more mileage by agitating for such a system.
Framework authors know far more about the edge cases that apply to the various browsers, and are able to “frame” a bug report much more succinctly. They also have a forum, be it a google group or whatever, in which to ask people to help bring it to the attention of browser vendors. They could provide a link where web devs can just visit and click a link or whatever, and that bug would be voted up (similar to reddit). Fixing browser bugs is in all of our interests’, but let’s take the line of least resistance.
Paul.
Steve (January 19, 2009 at 1:46 pm)
@paulhon – a two-tiered bug reporting system seems like a bit of a waste, to me. You report bugs to jQuery, they report bugs to Chrome. If you both have the same issue, then you should both vote on the same bug. If only jQuery reports on a bug or provides test cases, then it seems like only one person really cares.
Also, it doesn’t really cover the case of CSS or HTML bugs (only JavaScript ones), which I would say are much more of a pain to average developers, since we have nice JavaScript frameworks but no performance-effective way to glaze over CSS/HTML issues.
carlos (January 19, 2009 at 7:07 pm)
this is not the job of a web developper to send reports bugs, if you do that with “responsability” i do not agree, it’s in no case a dev responsability, you are misleading differents problems here. i completely disagree with your article, and found it completely uninteressing.
paulhan (January 19, 2009 at 8:14 pm)
@Steve,
Perhaps I wasn’t clear in my post. Most bugs are going to be found by the library developers first, through their unit testing systems. Sometimes, a user will find a bug first, whereupon (s)he will report it to the lib dev.
At the point of finding the bug, the lib dev is best placed to decide whether to try and fix that bug directly in the library, or file a bug with the browser vendors, and is also likely to be able to give a better description of how the bug manifests itself.
The browser vendor may not be aware of how much of an affect a bug might have on a web site/app.
So, if there was a voting system akin to reddit or stack overflow, on the browser vendors bug tracker, the lib devs could inform their users, the web devs, that a bug had been filed and web devs could then go to that bug and vote it up. Now browser vendors know how important fixing a bug is to people and can allocate resources accordingly.
F1LT3R (January 28, 2009 at 2:23 am)
Awesome post! I never really thought about it this way, as I’ve always developed specifically for the “Actual Releases” as that is what 99% of end uses will be using. This makes sense commercially… in the short term.
But you’re totally right, we should all pull our weight. And in the long-run we will all benefit. I was particularly interested in what you said about “open” browsers and knowing if your bug-fix is in the pipe-line… or even discovered. I think not knowing what’s happening with my feedback would be the number one discouragement when considering the build of a good test case.
Switching to nightlies. :)
KooWii (February 28, 2009 at 5:02 am)
So much to be a designer. I don’t understand really well about the bugs but I do hate it when there is bugs attack on a website.
Daniel Katz (April 3, 2009 at 8:30 am)
First of all, thanks for the great article.
Second, I wander, where can i report bugs in ie8 now? I’ve checked at [connect.microsoft.com/IE] and it is not longer possible to report new bugs there. So, do you know where can i report a bug now?
Kent (April 27, 2009 at 10:05 am)
Great post. I always complain about the bugs and compatibility issues, but never really thought about reporting them. I don’t know that running nightly’s is a viable option for everybody – but we could all gain by contributing to finding fixes for issues.