Hacker News Reader

Comment by silverwind | Hacker News Reader

Amateurs, Firefox has 20+ year old bugs open and just recently fixed an 18 year old one.

I have entirely given up on getting Firefox bugs fixed; considering stuff like the entire browser crashing because the GC gets starved during heavy load [1] to seemingly having no control of their file handles at all [2]... The chromium team is a fair bit more receptive/reactive. I wish Firefox could get their priorities straight.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1790500 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1792598

My experience has tended to be the other way round. I’ve filed quite a few bugs in Firefox over the years, and a handful in Chromium. Filtering to similar sorts of reports (since many of my Firefox reports are using-the-browser related, and often dealing with regressions since I’ve used Nightly for ~11 of the last 13 years, whereas my Chromium reports have only ever been for things like rendering errors), most of my Firefox reports have been dealt with fairly promptly (though some linger), whereas in Chromium I don’t think I’ve ever had prompt action after initial triage—a couple have been fixed incidentally two or more years later due to replacement of a large component, but I think that’s it.

(My experience is almost all more than two years old. Haven’t needed to file much in the last couple of years.)

I once had a fantastic experience with reporting a bug on Firefox. One engineer saw that the bug was severe enough to justify delaying the release process, they worked their asses off to fix the bug and merged the bug into the new version which was released with just a little delay. That was amazing to watch.

In general I have the feeling that Firefox and Chromium developers take bug reports very seriously. Safari is a different story, my bug reports there got frequently ignored. But I have the feeling that the entire Safari project is handled by one single developer, so it's not really surprising.

I feel that Firefox has been increasingly focusing on adding fancy new features rather than ensuring the browser is stable and functional. Accounts, Sync, Pocket, to name some examples.

If we include the android edition it's easy to mention the UX customization options as another example. "Scroll to hide toolbar" frequently breaks the viewport size calculation, making it impossible to scroll to the bottom of most pages. "Pull to refresh" keeps triggering when trying to scroll up on pages. "Swipe toolbar to switch tabs" is great, even though it occasionally sends you to the new-tab splashpage which I'm still not quite sure how to effectively return from. And the decision to make most addons unavailable is just confusing through and through.

I get the motivation to add "some value" to set Firefox apart from the competition; I just wish it was a far second to bugfixes.

"I wish Firefox could get their priorities straight."

I guess the target for complaining would be rather Mozilla, who rather drastically cut down their engineers. I think those who remain, do all they can, with their limited manpower.

Well, some bugs actively hurt their ecosystem, like the bug in Firefox for iOS that sends corrupt or missing cookies after the application has been tombstoned and is launched again[0]. This will cause you to get logged out of many sites, which in turn makes you use a different browser and at that point you might as well use Chromium on your desktop as well.

[0] https://github.com/mozilla-mobile/firefox-ios/issues/12279

Mozilla corp.'s misaligned priorities far predates drastically cutting down their engineering force.

"no control of file handles at all" seems like an unfair categorization of the actual issue: file handles backing the JavaScript object are closed when the object is GC'ed, which may not happen immediately after it's done being used.

I'm not sure how this could be fixed. Knowing that the file isn't used anywhere else after you upload it would require a full gc pass in the general case even if it's obvious in your snippet, right?

I'm on my phone or I'd check if chrome on Linux has the same issue. Do you know?

Never closing the file handle on macOS is much more serious, but you don't mention that in the body of your bug report, just on your linked page with a repro demo.

Chrome behaves correctly on Linux, macos and windows, I can confirm that much. Files are immediately closed when they are no longer in use, either by a FileReader() or by an XmlHttpRequest.

Firefox /appears/ to immediately be closing files as well, as long as they are only accessed by a FileReader and not by an XmlHttpRequest, however this could just be luck.

And I agree my phrasing was suboptimal on that part. I recall that was the first impression I had when encountering the issue and misremembered the details.

Reply on news.ycombinator.com