SVG Chromium bug is more than 10 years old | Hacker News Reader

SVG Chromium bug is more than 10 years old

bugs.chromium.org

93 pointstansan59 comments

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).

fs is a legend

FS also co-authored the pre-chromium (presto) SVG engine in Opera so he probably has a unique perspective.

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.

bfgeek has been a TL on Blink for many years. Dude is speaking from his expertise.

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.

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.

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 mean that commenter also didn't fix it in the last ten years. Chromium is open source isn't it?

Maybe the commenter is less than ten years old. Otherwise they have as little excuse as the rest of us.

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.

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.

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.

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.

I agree with what you are saying.

But this guy from Russia came in, threw a fit and was never heard again in this bug.

And still, the reply was polite.

I am sure there are tons of more bugs in the chromium project that are 10 years or older. Some things are just more critical than other.

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.

>but it's run by Google for gods sake

So? Google still has a team assigned to the project, and that team has limited people, and it also has preferences and priorities.

> Chromium is open source isn't 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.

https://opensource.google/documentation/reference/thirdparty...

Google allows WTFPL third party code.

That probably complicates things from a legal perspective. I could imagine that that patch can no longer be submitted by anyone.

Have you ever looked at the Chromium source code?

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.

The reality is that it just isn’t that important.

Man, that comment has a lot of “I’m the main character” energy.

And???

Sometimes a bug just doesn't have the same importance to the maintainers as it does to you.

If it's that important, fix it yourself.

Yeah... There are 10 year old Android bugs that annoy me too and "fix it yourself" is a terrible answer.

You know exactly what would happen. You make PR, and then.... Nothing. Enjoy all that wasted effort.

First of all, I don't know that would happen - it looks like the maintainers are open to the patches.

And second, it's still not wasted effort if you get the fix that you need.

> 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.

I thought it was cool to find an issue this old and still being worked on, so I shared it. It was nice seeing how much work goes into it.

What's your problem?

Seems like the guy from Opera has implemented the first 90% of it. Now only the remaining 90% left.

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.

I think that fs guy is a legend after reading the comments. That person has been just grinding on all the issues for years.

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.

https://bugs.chromium.org/p/chromium/issues/detail?id=130573...

Vector GPU Rasterization in Chrome is still broken on Apple Silicon Macs. Has been for more than a year.

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.

Browsers can't really unilaterally deprecate W3C standards especially when its already implemented in competing browsers.

Because browser engineers need to work on more useful features such as EME or Web Environment Integrity API

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.

What do you think is going to happen before it's displayed?

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.

https://stackoverflow.com/questions/33087256/how-to-gradient...

A developer running in to problems trying to use this

It feels really strange to see this known issue go unaddressed for such a long period since Chromium is the current market leader.

The implementation needed is very non-trivial and the problem crops up too infrequently to justify shifting priorities to fix it.

If its more than 10 yrs old -> It's not a bug its a feature!

Sometimes I wish somebody would design a new format to replace HTML entirely.

Reply on news.ycombinator.com