Writing negative replies on bugs like this isn't constructive (like #c89).
Browser engineers have an extremely difficult job. The codebase is incredibly complex (they aren't just copying data from one system to another - it takes years to get up to speed in just a small area of the codebase) - any change (even improvements/fixes) risks breaking websites.
You might think you are complaining to a faceless organization, but in reality your really just talking to 1-2 people. Be kind. Each time an engineers gets dumped on you risk them throwing in the towel for good (engineer burnout is real), your bug will very much not be fixed then.
Engineers like fs@ are one of a kind and experts in their area. (fs@ implemented SVG favicons to Chromium for example - https://bugs.chromium.org/p/chromium/issues/detail?id=294179 ). As the web platform is so expansive there are really only a few people in the world at one time who understand various problems deeply enough to make progress on a fix.
What does help? In this particular case - if you are affected by this bug starring it helps. If you can kindly describe how this affects you - that also helps. The Chromium project actively tracks highly starred bugs. (Keep in mind the project also takes into account "gaming" the count so getting 100 people to star the bug mindlessly wont help).
I admittedly can be sharp in bug reports for obvious breaking bugs with companies like Adobe and Microsoft. I know what it's like from the other end— I worked as a developer for a decade, and before that, I worked in code-level support in a very large dev organization for a few years. Frankly, a lot of the shit I shoveled in support was totally justified, and sadly, the squeaky wheel does often get the grease. Often you don't even make it past support unless you become an "irate customer."
That said, it's pretty clear when you're up against an org like that, and communicating that you are angry because you are experiencing hardship from an unresolved issue in software that you license never, ever warrants personal attacks; implications that the developers are lazy, stupid, or disorganized; implications that they're maliciously withholding fixes, etc etc etc.
And beyond that, there's no excuse for being cranky in bug reports for free software or in small fora like issue reports on repos that go directly to developers, or anything like that.
To be fair, #c89 was posted in Q4 2021, almost 2 years after the last post from the devs in Q1 2020 which said the bug would be fixed in Q1, and there was no response on an earlier request for a status update.
I dunno... that comment you linked to was clearly annoyed and not terribly useful, but I will note that it was at least funny; I got a lot of flack as a single-person maintainer of open source projects and I wouldn't have been much at all phased by that comment (and neither, it seems, was fs@) even though in my case it would have inherently been a lot more personal as I would have no one else to shift the blame to.
Regardless, the answer to that comment says that the reason why this but wasn't fixed yet is due to "priorities"... which I guess makes sense as Google would rather allocate people to working on Web Environment Integrity than bulking up the "1-2 people" you say are working on this part of the code. Remember: the large tech monopoly isn't our friend, and the people who work choose to work at one deserve our collective scorn.
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.
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.
"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.
The `<use>` element in SVG can target an external source and clone it into the shadow DOM. However, there is a bug that prevents it from copying certain elements resulting in an unexpected SVG.
One commenter puts it into perspective:
"How is this still not fixed 10 years later? This bug is now just as old as Voyager 1 leaving the solar system or Lana Del Rey debut album. We went through an entire Spider Man reboot cycle and 3 James Bond movies. A whole generation of consoles came and passed by with PlayStation 4 being both released and superseded by PlayStation 5 while this bug was open. This bug is older than Grand Theft Auto 5. We live in a whole different world now, especially considering the pace web is developing and we STILL cannot store an icon with a gradient in an external SVG sheet."
I get the frustration but on the other hand there’s an expectation here that the software must be absolutely bug free and I just don’t see that ever happening.
To look at the metric another way: 10 years, 120 months. 95 comments (including all kinds of automated comments). So less than one a month, among a small group of people. Fixing the bug is clearly not just a one-line thing and requires a ton of effort (including the loading of external resources, which always requires security consideration), which doesn't bode well when compared with the size of audience clamouring for it.
This is such a bad faith argument whenever I see it, when an end-user is commenting on a project, at least that is funded and has a dedicated team working on it. Asking for something to be fixed, doesn't have to warrant such a reply.
I can see if it was some obscure project or some solo dev project, but it's run by Google for gods sake.
People don't like it, but even if you are a solo dev open sourcing your stuff a product that expects non tech people/even Js developers, expecting them to open a PR for your coded in some low level language instead of letting you know how much priority it might take is wrong IMHO.
What we also forget is that Chromium (+ HTML, Javascript, SVG, ect) is starting to be in a market dominance position where Windows was in past decades: We're at the mercy of a market winner who improves it at their pace.
At times, it appears that web standards have evolved from their open nature to primarily supporting Google's agenda. If Google wants a certain product to run the browser, they will bend the standards to do that.
I bet as soon as a Google product needs this feature, the bug will be fixed.
But Chromium is open source. Opera and Microsoft, among others, contribute frequently. Igalia is a consulting firm that takes commissions for Chromium browser work. So the correct statement would be that anyone with enough time and/or money could make this work, not just Google.
This is called "the paranoid style", political scientists talk about it as a unique feature of American politics.
It's hard to interact with because falsifying it requires invoking it yourself.
ex. here, we'd have to say "I bet you'd be right here complaining if it was fixed that Google was allowing arbitrary remote loads in not provably secure context." It requires a whole lot of supposition and negativity.
Oh, probably. That's a pretty standard pattern; I know of a feature that was lacking from Apple's window manager until they found a need for QuickTime to use it and added it in.
Posting this link to HN (and then describing some unrelated events of the last decade) is asking for it to be fixed? No, it's just griping loudly about one's pet bug, which is one of a zillion in a project as large as Chromium, hoping that somehow this shames Google into reprioritizing it.
Being open source doesn't mean that you can contribute to it at all. In this particular case, Google does actually take contributions, but only from people who signed their CLA, and many people aren't going to agree to that.
What would happen if you throw a patch into their discussion without signing CLA and with WTFPL license? Can someone else take that patch and resubmit it with proper procedure? Sounds like a good approach if you want bug fixed but don't want to sign any agreements.
WTFPL is not a good license for the same reason that "public domain" isn't good. It's not actually recognized internationally. Copyright is the basis of viable international licenses and they need you to turn over the copyright to them (or license it to them or whatever their CLA says).
So, if you did that it'd probably be worse than useless because it might hamper the legal adoption of identical or near-identical code if the fix was such that there was essentially only one decent solution.
> And second, it's still not wasted effort if you get the fix that you need.
Putting aside the impracticality of building Chrome or Android from source in perpetuity - and the fact that you'd actually end up with Chromium and AOSP - what good does it do if you fix a bug for one user? You still have to deal with it existing for 99.99999% of users in your app/website.
The "guy from Opera" has done amazing work on SVG in Chromium. I hope he will be able to contribute a few more years, because it will be difficult to replace him.
let's go through this again: just because a specific bug might be important to _you_ does not mean it is important to anyone else. You might thing bug 109212 is obviously important, but there are hundreds, if not thousands of other bugs that are just as old, that might be important to someone else. The Chrome folk fix the bugs either directly important to them/google, and the bugs that are important to the most people. That's basic prioritization, and anyone who thinks that bug priority should be a function of age, rather than real world impact is bad at prioritizing.
This also isn't a solvable problem: Google cannot simply hire more people to fix more bugs (mythical man month, remember?).
The reality is that if you have a pet bug, that is specifically important to you, and not important to anyone, is not a security bug, and isn't a feature regular users or web devs are clamoring for, you're probably going to need to fix it yourself (or pay someone else to). Given a choice between paying an engineer to spend time fixing a bug that has no significant impact, and paying that same engineer to work on something that thousands/millions will benefit from, or something google directly benefits from, google (or any employer) is going to choose one of the latter options. That's just sensible management.
Apple should probably get on fixing that; their new architecture broke a popular application on their platform, and that could cost them users.
(I'm being tongue-in-check, but those who know the story of Microsoft beating up their APIs to keep Adobe happy know that's actually how this goes sometimes. "Who's gonna pay the cost for this being broken?" is a business concern as much as a technical one).
And yet somehow, we all survived. This suggests the right course of action is to explicitly deprecate that use case and throw an error, to decrease the complexity of implementation.
Chromium still doesn't support SVG icons in browser extensions either. Not as extension's own icon or in the browser toolbar. Firefox has supported those for years. Chromium just scales the images to the nearest 16-dip.
Magic of course. Talking seriously, it's one more step you'll have to take care of when making extensions for multiple browsers. Using SVG's directly would be much more simple for the devs.
I thought you were suggesting chromium automatically scaled the SVG for the various sizes it needs. Are you saying you have to do it manually? That does sound like a nuisance.
These complaints about Chromium and Firefox bugs make me sad. Wasn’t the whole point of open source putting the user in control. That way they did not have to go begging to the vendor to pretty please fix this bug that is affecting them.
What is the difference between these begging, cajoling bug reports and similar bug reports for proprietary closed source software?
Seems the software is just as centralized and the commercial company is just as much in charge versus the user.
Browser engineers have an extremely difficult job. The codebase is incredibly complex (they aren't just copying data from one system to another - it takes years to get up to speed in just a small area of the codebase) - any change (even improvements/fixes) risks breaking websites.
You might think you are complaining to a faceless organization, but in reality your really just talking to 1-2 people. Be kind. Each time an engineers gets dumped on you risk them throwing in the towel for good (engineer burnout is real), your bug will very much not be fixed then.
Engineers like fs@ are one of a kind and experts in their area. (fs@ implemented SVG favicons to Chromium for example - https://bugs.chromium.org/p/chromium/issues/detail?id=294179 ). As the web platform is so expansive there are really only a few people in the world at one time who understand various problems deeply enough to make progress on a fix.
What does help? In this particular case - if you are affected by this bug starring it helps. If you can kindly describe how this affects you - that also helps. The Chromium project actively tracks highly starred bugs. (Keep in mind the project also takes into account "gaming" the count so getting 100 people to star the bug mindlessly wont help).