Firefox could be a lot better with usability issues, too. They will agree on something being an issue and then let the ticket sit there for months and years, even if it's something that's easy to fix and should be prioritized.
"should be prioritized" is a very subjective statement. Out of every 100 tickets, there is 50 people who believe theirs is the most important one. And we have over 200k tickets total (not all are bugs, many are resolved, but the scale is massive).
If you think a bug is easy to fix, pleasez consider providing a patch.
I find it hard to believe you don't know that casually contributing to Firefox is ridiculously hard. The build system is borderline insane, building takes hours, and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer. I have tried contributing a couple of times. Thank you, no more.
I casually contribute to Firefox and it's not ridiculously hard. It is a somewhat steep learning curve if you contribute for the first time, primarily getting acquainted to the build system, the area of the code you're fixing, and then finding the right people to nag about reviews, but it is far from ridiculously hard.
It used to be ridiculously hard, back in the days of hq merge queues or even cvs, I give you that, but the general build stuff improved a lot since then.
The build system is hg clone/git clone + ./mach bootstrap + ./mach build... And there is a lot of docs for it too. I wouldn't call that "borderline insane".
Submitting a patch for review is a only moz-phab command away (after you set it up once, which took me under half an hour).
A full build on a slow machine can take hours indeed (on my 2015 macbook it takes about about 2 hours I think, but my beefy desktop finishes in under one hour). But you often do not even need a full build, but an artifact build[1], which brings it down to a few minutes and just a few seconds on rebuilds (./mach build faster).
>and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer.
Now that's actually a problem. It's usually not that they are too busy to respond, but that they do not read their bug mail (because they get thousands of emails a day). That's why you either have to actually request a review or need-info them on bugzilla. That usually draws their attention, simply because review requests are listed in a neat list and need-info-s are listed in another neat list, and if that still fails to grab attention, there is enough folks on the irc channels who can either help you directly or point you in the right direction.
./mach bootstrap will usually help you set up your environment mostly automated after some confirmations, and will ask you if you want to do full builds or artifact builds, too
Compared to other software of similar complexity I think standing up a Firefox build is actually pretty reasonable. The bootstrap instructions are not complicated (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...) and the build takes about an hour on my laptop. Chrome is certainly a lot harder and takes significantly longer (if you lack access to Google's internal build farm). Likewise the Linux kernel is also tricky and slow to build the first time.
I have found contributing to the linux kernel a significantly more pleasant experience than contributing to Firefox.
I have no trouble believing that contributing to Chrome is even harder, but then again I didn't hear someone from Google saying "If you think a bug is easy to fix, pleasez consider providing a patch."
I mean, Google doesn't even pretend to be open to community contributions. Pretty much every choice they make is tailored to googlers only, just look at their build systems. They're upfront about it which I think prevents me from complaining about how hard is to contribute.
I'll take Mozilla over Google every day, but if Mozilla presents itself as open to community, it also lends itself to criticism that Google avoids altogether.
So yes, that happens, and if that's not as easy as we could have hoped, probably help is welcome with that as well.
Big and complex projects generally have higher standard of effort necessary to get the leg in. The comparison to Chrome was that it's a project comparable in complexity, and yet Firefox is easier and faster to build.
I've submitted many browser bug reports to Google, Microsoft, Apple and Mozilla over many years. I only bother to submit issues for "important" bugs, I write clearly, I simplify, and I spend significant time ensuring that the bug report is useful to developers and relevant for users.
Google respects my efforts, and often fixes my reported issues, or at least explains why it can't be fixed (usually with well reasoned answers, usually the actual developer is communicating with me).
Microsoft/Apple/Mozilla waste my time, ignore my efforts, and generally that results in a poorer user experience in the browser.
The Chrome team is one of the most amazing software teams I have ever been tangentially involved with - and the product quality shines.
I suggest Mozilla look at the last 6 months of bugs submitted and do some analysis on them.
Ideally take a subsample and talk to the submitters, and see what they think.
If Mozilla agree that Google do a better job than Mozilla, then benchmark against them.
I eventually stopped reporting bugs to Mozilla, Microsoft and Apple unless I absolutely had to. I recently stopped working with browsers, so I no longer have much appetite for helping.
I consider that vastly better than the Chrome approach, which just robo-closes all bug reports more than X months old and tells you to open a new ticket if you still care. This happened even if there was traffic on the ticket indicating that yes, it was still an issue and affecting multiple people.
I stopped bothering raising Chrome bug reports years ago.
If it's a js/css/html/xul-only fix (and chances are good it is, when it's a usability issue, as the frontend/UI code js on a high level), then you do not even have to really build Firefox but can use artifacts mode[1], which takes a few minutes for the initial build and only a few seconds for subsequent builds.
Then find a reviewer. I usually look at the recent activity of files I touch (or related files, or related bugs), find functional changes and just add whoever reviewed those most recent changes. Even easier when it's regressions, then you can see who reviewed the regressed changeset and who wrote it and CC them as well.
If the person(s) you picked do not want to review it or cannot review it, they will tell you, and usually suggest who else to ask.
If this doesn't work, then you can always ask/nag on IRC.
