Hacker News Reader

Comment by meindnoch | Hacker News Reader

TL;DR: they are mad because of:

1. A genuine (?) Safari bug with the CompressionStream API. (we never learn what the actual bug was, and their bugreport to WebKit was literally just that "hey, our website at URL ... doesn't work" - no minimal reproducible example whatsoever. Lol)

2. An issue due to them relying on a Chromium bug.

3. An issue due to them assuming that OffscreenCanvas will always support both 2D and 3D (WebGL) contexts.

View on HN

It honestly impressive how quickly they get a fix. Sure it take seven days for someone to get to the bug they filed, but from there it's fixed in 12 hours.

The post makes it sound like both Mozilla and Google are better at handling releases, but Chrome has the service worker bug, so I don't know if that's actually true.

I get that Safari is sluggish, at least compared to Chrome and is currently lacking features, but doesn't it seem like they've picked up the pace in the last year or so?

> I assumed it would have parity with the standard <canvas> element. Why wouldn't it? The MDN documentation mentioned nothing about inconsistent availability of contexts.

only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse

I've read the standard [0], to be fair there is nothing in there explicitly indicating that some contexts might be unsupported, except the vague "if this does not throw an exception" condition, which is easy to miss.

[0] https://html.spec.whatwg.org/multipage/canvas.html#the-offsc...

These were just a few issues with the latest version. Similar problems have occurred with past releases for years, and it seems the author is justifiably stressed out over the lack of transparency and never being sure if/when a breaking change is about to occur for customers using Safari.

> TL;DR: they are mad because of:

This is not a good summary of the article. They're aren't mad at the bugs, they're mad at how Apple handles Safari releases (as seen in the very title of the article).

If you read the "how to fix it" section, the fixes are "transparency", "update Safari independently of the OS", "more pre-release testing options", "communication".

Release schedules &c. aside, they have no argument if they're complaining about the Safari team's "communication". The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.

> Release schedules &c. aside, they have no argument if they're complaining about the Safari team's "communication".

You can't put that aside, because it's the entire point!

"The bug is fixed in the git repository, but we refuse to tell you if or when the fix will appear in Safari" is communication, but it's not the kind of communication needed for web developers.

> The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.

I have to disagree there.

> You can't put that aside, because it's the entire point!

Sorry I didn't mean to imply it wasn't relevant, merely that I wanted to address one small sub-point of your comment.

> is communication, but it's not the kind of communication needed for web developers.

That's fair, but it's relative: a quick response with a commitment of work (if not of timelines) & active dialogue on debugging efforts (due to the complete lack of effort on the part of the reporter) is a LOT better than no commitment or response, or a "please provide more info" / "WONTFIX" / CNR. Which is much more common.

Particularly given I think a "please provide more info" would've been a perfectly reasonable response to the first report.

Reply on news.ycombinator.com