Hacker News Reader

I agree with you. I work in software development and have followed Mozilla's bug tracker for over 5 years, and i STILL don't really understand how to use Bugzilla.

On the dozen or two occasions that i've filed a ticket, probably 1/3 of them ended up being duplicates (which i always search for, but never find, because i don't get how to use Bugzilla's search function), and another 1/3 end up going un-acknowledged. The remaining 1/3 get acknowledged, but i've yet to see one actually get fixed (which i understand is a function of resources and blah blah, i'm not bitter about it or anything).

On one occasion, i was able to locate the source of the bug i had, and, even though i had absolutely zero experience with 'lower-level' languages like C++ at the time, i decided i would fix it. I pulled trunk and managed to build it, which was an enormous affair, let me tell you, and in the end i had a fix. I submitted the patch, but was told that i would need to put it through their testing system. I was given a link to a wiki, but this entire process was just absolutely beyond me at the time and i bailed on it. I just wanted to help them fix a bug. The bug is still there to this day.

To Mozilla's credit, they did (do?) have a user-feedback extension with the beta/Aurora builds that allows regular users to report bugs in a simple manner directly from the browser. You'd pick 'Firefox made me sad' and then just type what the problem was and click submit. However, i have no idea where these bugs go, how closely they're looked at, or how successful they've been in reducing bugs.

These reports are stored in Input: https://input.mozilla.org/ You can file them on all release channels now.

Reports are looked at by the Support team, and bugs filed. You can read more about the service here: https://input.mozilla.org/en-US/about or, if you are so inclined, look at the code (or even submit pull requests) here: https://github.com/mozilla/fjord

Additionally, Input sads are displayed on monitors in Mozilla's offices. I would read them all as I ate my lunch.

Speaking as an individual (not representing my employer, yadda, yadda)

> The bug trackers involved are among the most user-hostile and over-complicated interfaces I have ever encountered.

Please provide detailed feedback why that is. If you work with any given system for a while, you develop blind spots for its flaws, and so the devs on the respective projects are likely not even aware of the hideousness. (Except "oh, it was always that way")

> Developers[...] with at least three different flavours in the works [...]

If you have a repro case and a version number, that's more than enough. Yes, testing with latest is appreciated (and at least Chromium allows Canary side-by-side with your stable), but the repro case is what really matters.

If you have that, it is infinitely easier to actually react to a bug than anything filed that's just a vague description.

> Quality of implementation is obviously not the priority

It is a very high priority, in my perception. File a bug, please. The devs might not get to it directly - but that's due to the fact there's a lot of stuff that needs to be done.

> Ranting on public forums is rarely constructive

You posted more than a rant - you mentioned several existing pain points. It's important for all browser devs to hear about them, so thank you for doing so. And the more info you give on what exactly goes wrong, the more likely it is to actually get addressed.

Thank you for your thoughtful response.

I think I should start with an apology to the Chrome team, because I realised after posting that I was actually thinking of the Chromium issue tracker and its Bugzilla counterpart, not the Chrome reporting mechanism under "Tools" and then "Report an issue...". The latter actually seems to be a very good starting point for reporting a problem.

Regarding the more challenging bug trackers, I think it might be instructive to consider those systems in the same light we would consider the kinds of web start-up we often discuss here on HN. We talk about having clear calls to action, and not forcing someone to sign up with their e-mail address before they can even see what they're getting themselves into, and the psychology of giving users clear choices and avoiding analysis paralysis. This is all good stuff, and it's just as applicable to writing a user-friendly bug reporting system as any other web app.

Take a look at https://bugzilla.mozilla.org, which is the top hit for the search term "Report a Firefox bug". On that page, there are four big options, any of which might be what I should do first if I want to help. There's also a text box, which has a label similar to one of the big options, a bunch of separate related links next to that box that again seem to overlap with the big buttons and additionally suggest that I might need some sort of plug-in to do something. There's another search box in the menu across the top of the screen, along with about 10 other links. There's another row of links below all of that lot.

Now go and look at http://www.google.com, which is what I used to find that page. Except that I didn't really even do that, because the one relevant box was right there in my browser already.

Suppose I don't immediately give up, and I decide that "File a bug" is the most promising option on the Bugzilla page. Clicking through there, it seems that before I can find out whether I'm in the right place, I need to deal with a page prompting me to log in. At least, I think I need to log in, because there are form fields that look like I should on top of the 4 other text boxes, 4 buttons that look like buttons, 1 other button that doesn't look like a button, 2 checkboxes, and 20 links also on the page. However, as a new user, what I actually need is to create an account, which is accessible via a link set in tiny, low contrast text in the small print several lines below the login form.

OK, so I've spotted that link, and I click through to create an account. The next page does have a lot of nice, large, clear text. In fact, it has a whole load of links that I can use if I need help on one side of the page and a load of things for me to read on the other side. This is a classic analysis paralysis situation: if I'm here to file a bug, do I want help or am I trying to help? At the bottom of the right-hand column is, in smaller text, a place I can put in my e-mail address to create an account, under scary-sounding wording about alternative e-mail addresses (which have something funny about them that I need to follow a link to understand, apparently) and about confirming things work before I can get on with doing anything useful.

At the bottom of the left-hand column of that page, under the generic heading "Feedback", is what actually might be the most promising link: if you click that and then click "Firefox makes me sad", and you ignore repeated attempts to divert you elsewhere, you get to what seems a useful page: a box to type in a problem and a place to add a link to the page where it happened.

Obviously I'm deliberately describing the system critically here, and I'm picking on Mozilla rather unfairly since Bugzilla is hardly the only bug tracker with usability problems. However, I hope that by being specific, I am making the point about how difficult it would really be for an average user to report a problem. I've taken more than half an hour to write this message, looking through numerous pages on Bugzilla to get this far as if I were a new user, and I haven't even got to the main bug reporting page yet.

Just to finish the story, the actual page itself has far too many options for any non-expert user to be confident with it as well, even for professional web developers who use the system somewhat frequently, but this doesn't matter all that much if most people never get that far anyway.

Perhaps the most unfortunate thing of all is that despite being willing to help, the first time I ever said all of that was in response to an HN post where someone seemed genuinely interested in why I thought there was a problem. I honestly wouldn't know where else to send it, or whether someone somewhere might care enough to do something about it if they knew. Maybe if it's here it'll filter back in some useful way at least.

Just on a sidenote: similar to Chrome, Firefox does have a user-friendly (almost to the point of belittlement) feedback process readily available via Help - Submit feedback... It leads to https://input.mozilla.org/en-US/feedback.

I was a little surprised that the submitted feedback is publicly visible at https://input.mozilla.org

I agree with the previous comment; optimization is fun for programmers but in practice, all the modern browsers are more than fast enough already.

The biggest problem I have is with browsers sometimes failing to wordwrap text. That should be trivial to fix, compared to the effort that's being spent on esoterica (wordwrap is already implemented after all, it must be just something in web pages messing it up). I did file a bug report for this with Chrome, a year or two ago, but to no avail thus far. Is there any way to get it into the pipeline for being fixed?

So I agree that there is a great deal of accidental complexity associated with filing bugs, and browser developers could certainly do better here. I also see that there is a certain disconnect between the perceptions of a browser developer/QA, for whom "stable" version means "outdated version" and those of a normal user. On the other hand, if you do web development work professionally (and I appreciate that you personally might not), you should seriously consider running at least the beta versions of browsers on a day-to-day basis, and consider testing in something even newer. If you don't, it's much more likely that a browser change/bug will regress your site for tens or hundreds of millions of users.

Having said that, I would much rather have a bug report based on an outdated — sorry, stable — version of the browser than no bug report at all.

As for the rapid release cycle, my feeling is that process dramatically decreases the bug count. It forces everyone to keep the code in a roughly shippable condition all the time, and provides early feedback if a problem is introduced. I don't have data at hand to backup this hypothesis, but I wouldn't be surprised if someone at Mozilla/Google did.

It is, however, unequivocally false that no one cares about the quality of browsers or that all the focus is on features. Browser vendors have suites of hundreds of thousands of automated tests that every commit must pass. They require tests to accompany code changes. There is a big emphasis on correctness in initial implementation and on maintaining that quality through subsequent releases. However, as you note, this doesn't always go to plan. But submitting tests to the W3C is one way to help make things better. Not only will these automatically get picked up by vendors for their automated test systems, as time goes on we expect it to become more visible who is passing what tests. So there will be a pressure to compete on correctness as well as performance. Of course much like performance benchmarks, if test conformance rates become a big visible thing, there is a temptation to start submitting large numbers of tests for narrow areas where you know that you do well and the competition does badly. Also, not all tests are equally important. So some care is needed in the way that conformance data is presented to prevent people jumping to conclusions from the fact that Firefox 132 scores 89% on the DOM MindControl API but Chrome 140 gets only 87%. Nevertheless, especially for professional web developers, submitting test cases for browser bugs is one of the most effective things that you can do both to get the bug fixed and to advance the state of the web platform.

On the other hand, if you do web development work professionally (and I appreciate that you personally might not), you should seriously consider running at least the beta versions of browsers on a day-to-day basis, and consider testing in something even newer. If you don't, it's much more likely that a browser change/bug will regress your site for tens or hundreds of millions of users.

Again, I appreciate what you're saying, and it seems a reasonable request. However, I think it's unrealistic for a lot of developers.

For example, I work on multiple web-based projects in various capacities. Right now, just to test changes on one of my sites before releasing them, I run manual tests on about half a dozen desktop browsers and several mobile devices. (Automated testing is great, but there is only so far you can get with scripting, particularly when it comes to things like rendering glitches and responsiveness.)

If I put a change live on one of my sites, or worse, hand it over to a client or ship a web app embedded in network-enabled hardware, I shouldn't have to be constantly checking for blatant regressions in basic functionality every few weeks. In fact, I didn't have to, until the teams behind various popular browsers and plug-ins decided that the kind of major/minor/point releases the entire industry had been using successfully for decades weren't sufficient and pushing out whatever was ready at an arbitrary six-weekly interval was a better idea.

As for the rapid release cycle, my feeling is that process dramatically decreases the bug count. It forces everyone to keep the code in a roughly shippable condition all the time, and provides early feedback if a problem is introduced.

That's an admirable intent, but it clearly doesn't always work in practice. For a vast and complicated piece of software like a modern web browser, slipping in an occasional regression in a corner case is all but inevitable, but there have been your-browser-doesn't-work-at-all scale howlers that have been pushed out sometimes too.

I suspect what this really exposes is an over-reliance on automated tests and a false sense of security if all of the tests pass. With development at this kind of pace, and with the distributed and partly volunteer-led development model for these browsers, perhaps there just isn't time for more comprehensive reviews and high-level planning/architectural work and so on, but there is a reason those things have value.

As for decreasing the bug count, I fear that what is actually happening is that there are so many now and the target moves so fast that many of us have just given up on reporting them. Certainly for our project bug trackers here, Chrome used to be worse by a factor of several for browser bug issues, but Firefox spiked after going to rapid releases and has held the dubious honour of being the worst major browser for quality more often than not since that time. Several of these projects use modern but mainstream features from HTML5 and CSS3, but I'm not talking about bleeding edge or obscure features here.

It is, however, unequivocally false that no one cares about the quality of browsers or that all the focus is on features.

Please notice that I was very careful not to claim that. I do, however, feel that as a matter of priorities, quality of implementation often takes a back seat to ticking feature boxes and to performance at the moment.

Again, this is based directly off our own bug trackers. I could have described canvas and SVG issues not far from the kind of things simonsarris mentioned earlier in this thread, for example, and others in CSS3 backgrounds and borders, CSS3 animation, HTML5 media elements, and so on. In contrast, while the pace of development for IE is slower, it has far fewer blunder-type issues in basic functionality these days, in our (obviously anecdotal) experience.

As a final comment, I'm interested in these W3C tests you've mentioned a couple of times. I had no knowledge of anything like that before this thread. If you can share some sort of authoritative/definitive link to how that works, I'd appreciate that, as it sounds like I should learn about it.

>In Firefox's case in particular, users are often asked to create a new profile, which AFAIK still requires command-line hackery and, from direct personal experience, carries a significant risk of corrupting or destroying your regular profile even if you follow the instructions to the letter. This is insane.

I have reported a fair amount of bugs to Mozilla over the years, and have never been asked to do this.

You seem to confuse what is mandatory with what will simply be helpful. All the things like creating clean profiles, producing test cases, are things that expedite progress on a bug. If it's a real, reproducible bug, it'll be looked into regardless of those things. And if it's not easily reproducible, exactly how much time should the developers spend before they move on to another bug that is?

> As I said, I'm a professional software developer, and as such I appreciate the value of good bug reports and feedback from users, and I hate it when users make blanket criticisms. But Mozilla and Google are among the most user-hostile organisations on the software landscape in this respect, and until they fundamentally change their approach, I don't see this situation improving.

This seems like a strange comment

What other large scale software do you use on a day to day basis that you can even find and report bugs instead of just sending them in to some companies /dev/null and hope they eventually get fixed

It's not only the difficulty in reporting bugs that is the problem, it's the rapid release cycle and the frequent regressions and bugs it seems to introduce. I don't know which of the other "large scale software" I use would have the same difficulty reporting bugs, because nothing else I use breaks basic functionality every few weeks.

However, for smaller-scale things, I've recently been in touch with a couple of on-line services I use and the manufacturer of a hardware device I bought about various problems. I interacted one-to-one or even one-to-many with some of their technical folks, with very satisfactory service in each case. No doubt there is a bug tracker somewhere on the other side and some new records got created in it along the way, but all I had to do was send a simple message describing my problem and then answer their rapidly-provided follow-up questions. I was happy to make the effort to do that, because they made it easy for me to help and gave me a feeling that my effort was doing something useful.

I would be just as happy to contribute usefully to supporting browsers if it was just as easy to do it. I want to help, and for a long time I really tried to do so. But I live in the real world, and I literally can't afford to spend half a day when no client is paying me just to do someone else's testing for them every time I find a bug in a major browser. Once in a while I could cope with, in the spirit of helping out. Several times a month just isn't practical.

This level of insanity is pervasive. And I suspect it could be mitigated by better reporting tools.

One of the things that Microsoft did really well was to enable their system to capture enough information to reproduce a bug based on what the customer was currently running. Seems like browsers could benefit from that too.

They did not invent that. For example look at the perlbug tool that has been part of Perl for decades now.

Agreed, perlbug is another great example. And it would take the heat off the user and make developers more productive. Click "send config" and blam everything needed to reproduce the exact environment in the message without any typos etc.