Safari releases are development hell
construct.net
construct.net
While it's fixed in webkit, the webkit team were unable to tell us if the fix would be in the shipping version of 16.4 and, despite discovering and reporting the bug before it even hit a beta, the shipping 16.4 has the bug.
I really feel for the team who are maintaining the code. It's clear they do a great job in difficult circumstances and it's several high-level policy decisions at Apple make things really challenging for them: they're unable to talk about when bugs and their fixes will (or will not) be present in release software; and Safari updates are tied to OS releases.
But I guess they will stand until there is external pressure to force them to change e.g. in the form of regulation allowing to bundle alternative web browser engines and not giving preferential private APIs.
For example, here's what Chrome does: https://chromiumdash.appspot.com/schedule. All the dates are tentative and sometimes slip, but an engineer can point people to it, say "fix X made the branch cutoff for release NNN", and you can get a pretty good prediction for when X will get to what sort of devices.
It took us over a year to realize this was the root cause for 2D barcode scanning issues - we had an information-theoretic failure mode due to the low resolution.
Safari is the last non-evergreen browser. As long as Apple insists on this policy it doesn't matter how good a job the WebKit team are doing; they're still hamstrung by the outdated release policy Apple enforces.
Luckily, soon Apple will be forced to allow alternative browsers. At that point, I hope Apple will spend some of its trillions on actually improving Safari, in order for it to stay relevant and competitive.
Safari seems to be the last bulwark against a Chrome-only web driven by features of the week.
Full Chrome/Chromium on iOS could very well end that, and I'm not thrilled at the prospect.
Personally I appreciate Safari's resistance to constant featurism in general, and conservative approach to features that are likely to compromise power usage or privacy. I have little desire for web apps to reach complete feature parity with native apps, or to have complete access to all hardware and OS features. Many developers may hate it and want to usher us into Google's PWA future, but I'm absolutely fine where things are right now. And I certainly don't want to have to use Chrome/Chromium for everything.
Lastly, as a developer, I don't like building on quicksand. And yet that's often what it feels like using web/JavaScript frameworks and browsers that change from week to week.
Nonetheless, OP's recommendation that Apple note which versions of Safari a certain bug is fixed in seems like a very good idea that should be adopted.
The pace of change in the frameworks world is completely independent of web and browser features. And the web is very backwards compatible — so new web platform features don’t rot the foundations of any existing web apps, assuming they use specified features.
Just pause for a moment and think who's proposing these standards. The same groups pushing for browser "featurism" sit on the committees that define these "standards". It's not meaningful to say that they're different things when they're all part of the same effort in different disguises.
I do agree releasing a broken implementation is bad, not clear what happened there. Aren’t Safari releases held back until a TP is free of critical issues? Was this not marked as critical due to being reported as an app issue instead of a Compression Streams or Service Workers incompatibility / regression?
No. Safari releases ship in lockstep with iOS releases.
This is because they all share code, and more importantly, security vulnerability fixes.
You might be referring to how Safari is updated independently of macOS on the 2 non-latest versions of macOS. But those are still released simultaneously with the OS updates, and Safari on the latest version of macOS is bundled with the OS update.
The separate Safari updates are only for back support of older macOS versions.
Given the diligence of the Safari team - especially in the face of the extremely lazy first bug report - it's kinda wild that this person thought it appropriate to post such a negative angle.
The second bug report wasn't even a bug: Chrome & Safari had implemented an unspecified part of the spec. differently to each other (specifically the implementation behind generating client IDs for fetch events in web workers -vs- the main window). The op is relying on an unspecified implementation detail for their app to work. Yet the Safari team actively treat it as a bug in an attempt to be more generally compatible with Chrome.
My takeaway from actually reading through the content of the post is that the Safari devs are responsive and approachable, even even the bug reporter is lazy. Which is more than can be said of many other browsers projects.
[1] https://caniuse.com/?search=CompressionStream
[2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...
As an author you have two main options:
1. Feature detection: check to see if the API exists in the browser, and gracefully fall back if not.
2. UA-sniffing: use the API only on browsers where you've verified that your program works correctly with its implementation.
There's pretty strong consensus on the web that authors should be doing (1), and that (2) is harmful to minority browsers. Every time someone says "the new feature works fine in Firefox if I set my UA to Chrome" they're complaining that the site didn't go with (1).
Yes, using (1) means trusting browsers to get their implementations correct, but they are usually very good about this and getting better. The http://wpt.fyi tests have been a big help here.
0. Wait: Don't adopt the API at all if it is only supported in Chromium, because it's highly probable that the API will have behavioral or API differences if it's implemented by other browsers in the future.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Compression...
If browser vendors are releasing the feature unprefixed, that is their signal that they view the feature as stable. It is the responsibility of the browser vendor to ship unbroken features and use vendor prefixes to unambiguously mark if something isn’t fully baked. It is not the responsibility of developers to stick their finger in the wind and try to divine when a feature has subjectively “reached stability”.
If you ship a bunch of features based on an assumption about how browsers "should" implement an API in the future and it breaks, you can't tell your customers "it's the browser's fault!" Regardless of what's "fair," it's your software that looks broken. So you can navigate that however you want. I choose not to adopt single-vendor APIs for this exact reason.
Indeed you can’t! Which is the core of my argument for why we also need to be able to properly UA-sniff browser versions. If browsers aren’t holding up their end of the stability bargain, they need to give us a way to version-detect and handle the problem on our end.
Right now what’s pissing me off about Safari is that with their left hand they’re delivering buggy implementations of standardized features and with their right hand they’re cutting off our ability to detect which version of their browser we’re running in (and soon, no doubt, whether we’re running in Safari at all).
"a problem repeatedly occurred" and page crashes all the time.
Only in Safari iOS 16. Worked in iOS 15. Works even in IE.
What kind of bug report can you make out of it?
They release new API but they "forgot" to test when website is added to home screen (PWA).
New API passes feature detection but does not work in PWA.
iOS and macOS Safari have different bugs also...
So you have to sniff user agent and other things to find out broken iOS versions and hardcode workarounds...
In either case, there are plenty of browser testing SaaS that give you real Mac/Win/Linux/iOS/Android machines for testing and debugging.
https://developer.microsoft.com/en-us/windows/downloads/virt...
It has a kind of distinctive feel of nonsense, I don't know how to explain it.
Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure.
Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.
Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.
https://arstechnica.com/information-technology/2014/12/windo...
> While there were early signs that the browser ballot screen was influencing browser usage in the EU, with Mozilla attributing some European Firefox growth to the selection page, long-term trends strongly suggest that it was next to useless. In spite of equally prominent placement on the selection screen, Opera's share even within Europe appears to have declined over the last five years. So too have Firefox and Internet Explorer. Chrome, however, has experienced significant growth.
Thats only true outside of the US though. iOS is >60% in the USA.
let f = document.createDocumentFragment();
f.appendChild(document.createElement("div"));
f.firstChild.outerHTML = (`<a href="https://bugs.chromium.org/"></a>`);
How is it bogus? outerHTML is an attribute of Element https://developer.mozilla.org/en-US/docs/Web/API/Element/out... and DocumentFragment is not an Element https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...
> No idea if it fails in Safari, too
It does.
Have you considered that it's just a Gecko quirk that it happens to work in Firefox? Where do the standards say it ought to work?
Re-read what is written. I'm setting the outerHTML property of an element, not setting it for the fragment (which is the only way that your response would make sense).
> Have you considered that it's just a Gecko quirk that it happens to work in Firefox?
No, because I'm not a moron.
> Where do the standards say it ought to work?
Exactly where you'd expect to find it: in the specification of the outerHTML property (Leithead et al. DOM Parsing and Serialization, Extensions to the Element interface, §7.1 Attributes: outerHTML. 2016.)
The div has a parent node but no parent element, because a document fragment is not an element.
[0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...
It has been a monumental waste of energy participating in this conversation.
Can you be concrete? (This reply doesn't really clear up anything about the previous comment.)
This contains two independent statements, (a) "If the element has no parent element, setting its outerHTML property will not change it or its descendants," and (b) "Many browsers will also throw an exception [on setting an element's outerHTML property if it has no parent element]."
Statement (b) is true, since Chromium- and WebKit-based browsers will throw an exception if the element doesn't have a parent node which is also an element. Statement (a) isn't browser-specific, and thus it is false, since on Firefox, setting an element's outerHTML will change it and its descendants if its parent node is a document fragment (which is not a parent element).
Where we differ might be that I don't see the "many browsers" qualification as applying to the first statement.
> NoModificationAllowedError DOMException
> Thrown if an attempt was made to set outerHTML on an element which is a direct child of a Document, such as Document.documentElement.
So I'd say the Notes section is simply imprecise.
The wording has not changed since the 2016 version of the DOM Parsing and Serialization standard [0]:
> On setting, the following steps must be run: 1. Let parent be the context object's parent. [...] 4. If parent is a DocumentFragment, let parent be a new Element with
> - body as its local name,
> - The HTML namespace as its namespace, and
> - The context object's node document as its node document.
But Blink instead throws a DOMException with name "NoModificationAllowedError" and message "Failed to set the 'outerHTML' property on 'Element': This element's parent is of type '#document-fragment', which is not an element node." This was filed as a Chromium bug last December and assigned a week later [1].
[0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...
I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.
There's an important and cool concept here about using the weakest link sometimes.
Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have.
If my app runs well on my iPhone 8, it's obviously going to scream on a 12.
Ah the sweet nectar of naivety. Godspeed to you.
Can't believe I've been a webdev 15 years. What's old becomes new, except for me that is....
https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
1. IE6, a titanic that that wants to harm the web so they can push their own ecosystem instead.
2. IE11, the incompetent and rarely updated browser that you have to support because a segment of your userbase is stuck with it.
This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role. Ensuring apple gets their app store cut.
2 is also the case, but that needs less argument.
What a retcon.
> This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role.
Of course it doesn't
> 2 is also the case, but that needs less argument.
It needs as much argument, if not more.
The primary reason for chrome being developed in the first place was to push the web into a place that stuff like Google maps, docs, and so on could exist at all.
> It needs as much argument, if not more.
Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
Retcon again.
> Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browsers, and want Chrome-only non-standards delivered yesterday to every browser.
To quote again, "But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."
> The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
I do web dev, and it is definitely not immediately apparent.
After IE6 achieved it's goal of destroying the competition, Microsoft literally disbanded the development team. Why would they do that for a very successful product? Because the web didn't have potential?
Firefox started innovation back again a bit, but it took chrome and Google's want to applicationize the web to really kick us into gear.
https://www.androidauthority.com/google-chrome-history-10256...
> A few days before Google Chrome launched, Google released a blog post titled “A fresh take on the browser.” The post explained that they were releasing this new browser because they believed they could “add value for users and, at the same time, help drive innovation on the web.”
> Third, Google saw Chrome as more than just a browser by developing it with rich, interactive web applications in mind. Lastly, it offered tab “sandboxing,” which kept the entire browser from crashing when one website crashed.
...
> And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browser
I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
And if you want to test Safari? You literally have to buy a dedicated piece of hardware for it. You wonder why it isn't tested?
So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
You have to buy extra hardware to test on it.
And you blame the developer?
What Google says, and what Google does are two very different non-intersecting things.
Edit: Google's maps and docs etc. ran just fine in WebKit. What Google wanted was control. What they did with that control we all know. For example, sabotaged Firefox: https://twitter.com/johnath/status/1116871237240852480
> I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
Doubt.
> So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
Funnily how I've used Safari as my primary browser since 2007, and I've been a web developer for far longer than that... and I haven't run into these issues everyone on HN pretends to have.
> And you blame the developer?
Yes, yes I do. Always. Even in the days of IE6 the problem was always with the developer.
> Doubt.
For what it's worth, my development profile is similar. I would say that Safari works most of the time, but I get browser-specific failures from it at a noticeably higher rate than Chrome-derivatives.
One memorable one, if you're curious, was triggered because of a minification step. Terser[0] has a special argument `--safari10` to emit code that's supported by Safari. I discovered this argument after running into the bug.
So the problem is with the tool, not with the Safari it seems. Without an explanation what "non-standard" is about Safari 10/11 it's on the same level as the rest of hand wringing on HN.
You're making an assumption. I'm not sure where you're getting that. From what I recall, it was common `const` or parameter declarations in nested scopes. Safari was (is?) unambiguously wrong.
Edit: here's the bug: https://bugs.webkit.org/show_bug.cgi?id=171041
The updates came in plugins tied to the Windows platform: ActiveX. Because that strengthened the monopoly, they were pulling the strings and setting the standards, at their own terms. Tie it to operating system versions, tie it to Office, tie it to the next product they want to promote. Whatever they like.
Why invest so hard in capturing the web in the first place, then? Their behavior is consistent with a push to keep people on windows as much as possible.
I mean you know there was a period of time where Safari existed and Chrome didn't.
"Want global web compatibility? Fuck you buy a Mac"
-Apple
Still better than "whatever we throw over the wall is now a standard" that Chrome has, and you can see people clamouring for those on HN.
It's easy enough to not use stuff like web USB, and in my experience chrome and firefox "get along" while a page (doing more advanced things) not built for safari simply will not work in safari.
The problem with safari is that Apple makes it so you have to use it if you want your site to work on it. Chrome, I can safely ignore.
I also literally can't use safari if I don't have a Mac.
I've yet to see such a page [1]. And I've been using Safari since 2007
[1] Unless it's built with Chrome's non-standards of course.
Edit: of course there will be pages broken in Safari (or FF) for no reason other than the sheer incompetence of people building them. E.g. we have an internal dashboard page that is literally nothing more than tables and charts. Ooops, "only works in Chrome".
There's also the minor case of nominally open audio and video codecs that Google pushes to device manufacturers on pain of removing access to its services, but even that hasn't affected me, or most people really, that much.
Developers are eating the problems for you because safari support is almost always a requirement.
This is a developer side problem, not a user side one.
> for no reason other than the sheer incompetence of people building them
Safari never breaks, but when it does it's because the developers are incompetent?
The fact it takes a bunch of extra work to support safari (in more advanced cases like graphs and dashboards) is the whole problem. I have every intent to kick safari out of any home game stuff I do.
The problems "developers are eating" are hugely overblown
> Safari never breaks, but when it does it's because the developers are incompetent?
In 99% of the times? Yes.
> The fact it takes a bunch of extra work to support safari
No, it doesn't. Source: web developer myself.
Of course, if you rely on Chrome-only non-standards, that's a different issue.
> in more advanced cases like graphs and dashboards
Graphs and Dashboards are advanced use cases now. Gotcha.
I've been in these threads many times, and it's the same thing again and again:
- Safari is holding back the web! It doesn't. Well, if you think that Chrome is web, then you're entitled to your opinion
- Safari is new IE! It's not. That it doesn't implement the 400 or so APIs a year that Chrome implements is a feature, not a bug. If your site ends up with a "only works in Chrome" badge, that is your new IE
- Chrome split from WebKit three years after WebKit appeared. And the only reason for the split? Well, to do the same thing you accuse Apple and MS of doing: control. And look how well it worked for them. Everything they do is now considered standard and gospel by the gullible masses of web devs.
And so on.
The irony is that it's Chrome that breaks the web often, and badly, but they get a pass because it's Chrome! They have the new shiny APIs!
You should embrace this; this is how the web should be.
I don't mean you need to buy a Mac. Instead, I mean that the web standards effort originally came up out of supporting diversity. There was a wider range of possible clients, on a wider range of "popular" platforms. As developers we had to cater to support diverging capabilities. Progress on API development was slower, but it was more evenly spread out. Today, Chrome lurches ahead of everyone else in terms of API feature count, mostly supporting Google's business aims, and many vocal developers seem to think they should only support one set of capabilities. The slower, broader, way was better, in my opinion.
Unless you have the option to use it for your product then the decision is ship a product using just your web developers and have it not work on Safari/iPads or hire iOS developers and build and maintain a completely separate app.
So it's a 6-7 figure cost to your business that could be saved if they supported that.
The Chrome team happens to throw something over the wall and ship it to production with no oversight. And sometimes complain that that they cannot hide it behind a flag because people are already using it.
There's no end of people right here on HN who scream bloody murder when Safari (and Firefox) refuse to implement some new Chrome-only API.
The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. But it's well documented that this is a temporary process, some Chrome visitors you get won't be eligible for trials, and it's not guaranteed that features in origin trials will ship. What are you thinking of where they just shipped something, without an OT?
For something to become a standard they way it's actually supposed to work is for browsers to come up with two independent implementations.
And yet, Chrome frequently ships APIs it calls standard with just Chrome as the sole implementor.
Literally "Note that .adoptedStyleSheets is used on about ~.8% of page loads in Chrome now. Backwards-incompatible changes are definitely an issue here." https://github.com/WICG/construct-stylesheets/issues/45#issu...
---
WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed)
Well, what do you know https://groups.google.com/a/chromium.org/g/blink-api-owners-...
"this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea. Other chromium-based browsers may want to know as well, via these channels."
Thankfully, there will be a change. At some point.
===
These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.
* With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that.
* With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)
Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place.
Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it"
And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...:
--- start quote ---
I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make changes because you shipped it?
I’m sorry but that’s just not how standards work.
--- end quote ---
> With WebMIDI they're saying they want to do an announcement before making the change.
Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.
I will however, take chrome and user choice every single day over Safari's monopolistic crap.
The mere fact it's largely successful by it's nature of being bundled should scream to you how bad it really is.
That's the problem, though: more and more as time goes on, Chrome isn't user choice. Sites that only work with or only perform as expected under Chrome are becoming more and more common. It's becoming a monopoly too, but enforced by developers rather than a platform owner (though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc), and I'm not sure it's really any better.
When (mostly) Chrome came up with Web Components, they immedieately re-wrote Youtibe with Web Components v0 (now deprecated). The polyfill for them was infamously slow on Firefox. Just another ooops in a long line of oopses: https://twitter.com/johnath/status/1116871237240852480
Then why is HN is screaming bloody murder when other browsers don't implement the plethora of Chrome-only non-standards?
Also, using non-Safari WebKit for everyday testing (will my newest commit break it? should I fix something before I send the PR?) but using the proper Safari for more thorough testing (e. g. before public releases, or when a bugreport can't be reproduced otherwise) is an option too.
(The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)
Let’s just throw in the towel now and rename the web to the Chrome Platform.
Or depending on your tolerance for legal grey areas, you can also download MacOS directly from Apple servers and run it in a virtual machine.
Or if your objection isn’t to paying money but rather paying Apple, you can buy second-hand hardware.
Probably didn't word my answer well: by "Non-browser based bugs" I mean bugs caused by the code of the webpage having logic issues/bugs (as opposed to bugs caused by browser JS issues or CSS/HTML implementation incompatibilities and such). Perhaps "browser-engine-related" would be a better term
So, I read the parent comment as referring to browser-engine-related bugs - things caused by a browser engine behaving differently, not implemented, etc, and not including in his numbers regular webpage bugs due to html/js programmer error.
This isn't a Chrome vs Safari issue (Safari is better, of course), it's the fact that browser development suffers from Apple's corporate wall of silence. In this case, devs literally suffering.
I'm basically guaranteeing full compatibility with everything, because everyone has to comply with IE's behaviour. After all, I put a "Best viewed in Internet Explorer", this way if it fails, people blame their browser and not me.
It's clear that they're still trying to undermine the web where possible, without it seeming too obvious or getting them into hot water re: the recent monopolization debate.
- Apple doesn't want others to dictate their development schedule.
- Some Web standards clash with Apple's privacy promises.
While I'd like Apple to do a bit more about those long standing bugs, I think the narrative they are actively undermining the web is short sighted. I prefer Apple's behaviour instead of Google's behaviour to actively monopolise the web...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
---
As a tangent. If it was Apple of, say, 5-10 years ago, I'd also root for them to get their head out of their ass and lead in https://open-ui.org/ (started, of all people, by devs from Microsoft). Alas, with the way they approach interfaces these days, I'd want them far away from leading :)
Webkit is releasing more often and closer to the standards now than they used to. I'm guessing Apple knows they will be forced to allow other engines on iOS and are finally making Safari a good product.
I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance.
I hope the C-level exec at Apple sees this and realises why more devs are going to go with Edge (lol) / Firefox support: the sales guys are running Apple now.
I mean, I don't think it's even close to beign modern day IE. Perfect? Far from it but definitely not as much of a pain as IE
It was not just that IE was broken in all sort of very odd ways, or that it was incompatible with the rest (and standard), or that it was essentially a monopoly.
It was all three. So a site built for IE would not work at all in other browsers if it used anything remotely advanced (and advanced back then was users events), you had to support IE to live (on anything but demo site), and doing so was hell on earth because the bugs went from top to bottom (the browser’s memory management had to be worked around, and there were no memory profiler, hell the debuggers only worked half the time).
Not that it’s any fun encountering a buggy browser, even less so when a feature is so broken you’d be better off if it were not supported and just did nothing or used a fallback and you now have to coerce it into that, and it does seem to be a recurring issue of safari.
But it’s no IE, at this point you’d need malice aforethought to get there.
This is the endgame of a monopoly. Other people start demanding others stop fairly competing with you.
I'd like to think I'm a competent dev.
I use Safari as my daily driver because the difference in performance/battery life on Apple silicon is worth whatever small incompatibilities I run into. It just doesn't ever impact me on a day-to-day basis in the way that performance and battery life do.
Good engineering is all about trade-offs and this is one that doesn't even require a second thought for me.
What also is cool in Safari is to zoom into a page so that everything gets bigger which makes it easier to read text or view pictures (not sure if this is the normal zoom a site has, or something on top OS wise). But a lot of sites are breaking that behaviour now, which results in either not being able to zoom or elements overlapping in weird ways, text not staying where it should. I wonder what CSS stuff is used there.
At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.
There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.
Standards compliance really is the name of the game, and I wish people like GP had more pull to force Apple to make these reasonable changes.
His second one in particular is his app relying on unspecified implementation quirks - the Safari devs are responsive due to a desire to be more compatible with Chrome's quirks, not because they've failed to conform to spec.
His first bug report is just lazy and devoid of any detail - completely relies on the Safari team to do the work of debugging his app for him.
I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.
I understand the stress, but why do they think their product deserves more of Apple's attention than Safari's own product team who undoubtably are working to hard deadlines?
This felt like a really, really long whine because they didn't account for certain issues, and I found the 'Apple employee' references to be a little crass
It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases.
I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier?
The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library.
The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour?
The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but…
… the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined.
It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.
Ahh, that's your problem right there, man. Apple don't change for you, for me, or for anyone who isn't called Tim Cook. They'll be out there doing their monopolistic, zero-sum, winner-takes-all, my-way-or-the-highway, straight-outta-the-'90s thing, forever and ever.
Apple doesn't care about developers really, as far as the company is concerned they're all little sharecroppers on Steve's garden. Any help you get you should be thankful for, because you have no rights there and never will have. Enjoy your Stockholm syndrome while it lasts.
"Most powerful" phone runs out of memory, but 10 year old Android can handle same site fine. It was working fine in iOS 15 also. And works even in old IE11.
Every iOS release is horror, what will be broken again...
Yes, I am angry and tired of Apple's lack of QA. Trillion dollar company should invest more in quality.
I sympathize with those who still do and I'm looking forward to EU regulations to allow other rendering engines.
Hopefully once the EU forces Apple to open up their app store I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
For me, Safari is het only browser I truly trust, because Apple makes money from selling me stuff, instead from selling me.
[1] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo... [2] https://www.theverge.com/2021/10/7/22715179/firefox-suggest-... [3] https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
A trustworthy browser holds itself accountable by making it's code transparent and it's intentions clear. Mozilla is terrible at marketing Firefox, but I'd argue they've built a much more amicable framework for the web than Apple has.
To be quite honest, I don't care. I'm just a single guy working in his spare time; I don't have the resources to keep up with a trillion dollar corporation.
I'm so done with the endless Safari-only hacks. I'm so done with having to push emergency updates because Apple decided to suddenly break half of my website in the newest version of Safari. And I'm so done with having to explain to my users that, yes, audio autoplay doesn't work on Safari, and no, it's not a bug, it's because Apple actively blocks it and won't let you decide for yourself if you want to enable it for my site, and all of that because they want to force me to build a native app (where I can autoplay to my heart's content) so that they can extort 30% of my income.
> where they obviously prioritise making money over the interests of their users.
...and Apple doesn't do that?
> because Apple makes money from selling me stuff, instead from selling me.
Are you sure? https://proton.me/blog/apple-ad-company
> I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
What do you need from a browser that Safari doesn't support? In my experience, everything except obvious bugs has an easy work-around that is supported by the other platforms.
For me: a download for Linux or Windows so I can test with the browser. A macOS VM, like Microsoft used to provide for IE development, would also be acceptable.
All my personal projects and even professional projects haven't supported Safari for this very reason.
It's also worth noting that Apple has the bad habit of discontinuing Safari Technology Preview support on older macOS versions faster than they discontinue Safari support on older macOS versions, which results in testing gaps for Safari on those versions.
Safari supports the last 3 macOS versions, while Safari Technology Preview only supports the last 2. Take a wild guess which macOS version gets the most new regressions from new Safari versions.
It's more like Xcode, where every point release breaks something. You need to design your software and your development pipeline to handle that.
Even Google isn't great in this but their continuous release schedule makes it less likely to break things in the wild because they get constant pushback.
I'm still investigating whether this is something that's actually changed with the not-exactly-spec for this WebKit-specific CSS property, but given the behavior I've already observed when trying to debug it, it certainly seems like a regression.
PS; I am not very well off, so buying devices merely for testing on a browser seem pretty overkill.
Re: The release timing/schedule problem, I agree that more transparency on the release date would be nice, but since it is tied to an entire OS release, they probably can't do that. The way to go is to keep an eye out for the beta release cycle of iOS. They will typically release 5 or more betas, and then one or more RCs, and then a GM, and then will start rolling out the update to users. There are several websites like Mac Rumors, Apple Insider, 9to5Mac where you can get a good temperature of where in the cycle Apple currently is.
IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec.
> After 16.4 came out you could check if it worked, and remove the patch at your own pace.
Great for regularly updated web sites but if you're making a tool you don't want to maintain it'll forever be stuck in a state where Safari performs worse because it isn't using the correct API. And that sucks for users.
In this case I would probably add an "if Safari >=16.4 then skip compression streams" check, but that check would probably still be there in a couple of years. Resolving the immediate issue of "the product doesn't work on Safari" gets priority but "let's see if Safari got their shit together" would be a low priority task for me.
There bad (or seemingly incomplete) spec implementations are how you end up with "your browser is not supported" plastered all over web apps. When Blink will inevitably hit iOS, Apple will have to do a better job placating web dev concerns if it doesn't want to lose market share.
* https://chromium.googlesource.com/chromium/src/+/main/docs/i...
> ...uses OffscreenCanvas when available
I think it's a mistake to write your code to automatically use new platform capabilities when they become available if you won't have an adequate chance to validate them first.
It's just too optimistic to believe a new implementation of a low-level mechanism is going to work exactly the way you need. (1) new things have new bugs; (2) changes are you'll end up depending on implementation details that will vary between different implementations.
It's your choice: (1) don't use it; (2) validate it before using it; (3) roll the dice on behalf of your users -- that is, use it without validating it.
Don't let religious beliefs around UA-sniffing cause you to screw over your users.
In most cases I have found that feature detection + a blacklist of problematic browsers is often a good compromise. But there is no perfect solution.
I use Safari as my main content browser but typically switch to Edge for development work.
Also when you read W3C specs it can get confusing pretty quickly, vage wordings, etc. Or have MDN documentation that doesn't describe particular behaviour that is defined in the W3C specs etc.
Isn't that like illegal or something? Like Microsoft got sued for it?
Spanning Tree Protocol? :D
Perhaps because WebTransport is still not even anywhere close to be to a web standard? Perhaps because its status is literally, quote:
--- start quote ---
works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C.
These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards.
--- end quote ---
Just because it's shipped in Chrome does not make it a standard that every other browser has to implement immediately.
Apple - beautiful hardware, crappy software...
Hopefully apple gets sued someday so we can stop using their horrible browser
The "evergreen" madness must stop for platforms that are app delivery targets.
Or do it like Java does it...
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.
only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse
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?
[0] https://html.spec.whatwg.org/multipage/canvas.html#the-offsc...
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".
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.
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.
If possible you should have automatic tests that you can run automatically in several browsers.
Some browser need to be the first one to implement new functionality, before there is a specification! Then the specification comes and often it's different then the already implemented API.
You should not complain about new features, and you should not complain when browsers follow specifications. Instead you should have tests, and encourage users to report problems.
Most browsers have a beta/review release, you can run your test on that, once per day, automatically. Use a program that automate mouse movements and clicks, for example Puppeteer for automating Chrome. (tip: also do performance test while you are at it, so you will know which changes affect performance)
A large part of the post's complaint is that not only does Safari not have a nightly build, but they don't even give advance notice of when their "technology preview" (beta) or stable releases are coming.
Chrome, by contrast, not only has a public schedule, but a public dashboard where you can follow along.
262503@main
April 3, 2023 at 01:23 PM GMT+2
262502@main
April 3, 2023 at 10:51 AM GMT+2
262501@main
April 3, 2023 at 10:17 AM GMT+2
I don't. If your web site doesn't support Safari then I will take my business elsewhere.
Unfortunately iOS users don't have this option.
Is there any statistic to back that up that safari users first blame their browser and switch to a different one before they give up on a site? And why are they still using safari in the first place if it happens so frequently that they made a habit out of switching browsers? I'm not convinced.
HAHAHA.
Are you not aware that every browser in iOS is basically wrapper for Safari?
New bugs in Safari will break other browsers also.
I haven't found that to be entirely true. Users will definitely have multiple browsers installed but that's usually because someone in their IT department had them install a second browser for testing. Most users will use one browser the entire time and need someone to tell them to try it in another browser if it's not working.
If every website works in Chrome and most websites work in IE, users will switch to Chrome. Same with Safari. If the thing you're building is interesting enough for users to return to it, the unsupported browser may just stop getting used all together, especially if multiple sites break at the same time (i.e. when Safari broke WebAssembly support).
Okay, how do I run headless Safari in a CI exactly? And how do I run Safari mobile in a CI since it has different bugs than the other one sometimes?
I'm sure some people hacked some stuff together with ducktape but you are far far outside the supported development cycle of this software.
Apple literally goes out of their way to deny you the right to use another browser engine on their mobile phones.
Please go and meet some of your users in person and watch them use a computer/phone. Your eyes will be opened to a world you never knew existed.