An Abridged History of Safari Showstoppers

TL;DR: ...

Todos

• Rank bugs: showstopper, minor
• Bugs without description.. leave it? Split into separate chapter? ("More bugs")
• Fact check
• Tone down? Or up?
• Review/improve IndexedDB API information leaks
• Add disclaimer? Way to send feedback / corrections?
• Add CTA (let us know if we missed anything / tell us your horror stories)
• Add section: final thoughts?
• Add section: "rough estimate of the fraction of time"
• Co-author / credits ?
• Write 'we' or 'I' ?
• ...

As noted elsewhere, a developer-lamented but regulator-overlooked aspect of Apple’s monopoly on iOS browser engines has been the prevalence of show-stopping bugs.

We define “showstoppers” here as bugs that cause working apps to become entirely broken or inadvisable to use on the web.

All browsers have issues, but iOS is unique in depriving users of choices that developers can recommend when the system-provided engine breaks. Users and developers have literally no choice; they can’t choose a different browser to work around Apple’s frequent bouts of platform breakage. How bad is it? To get a sense for the impact, we’ve laid out the worst issues of the past decade and, at the end, generate a rough estimate of the fraction of time when web apps would have worked as advertised on iOS but for Apple’s implementation…hiccups.

Showstoppers by Year

2014 - Completely broken IndexedDB implementation

Apple shipped IndexedDB with iOS 7.1 (March 2014) but it wasn't usable until iOS 10 (September 2016) due to "seriously buggy behavior as well as complete lack of support in WebViews".

Unfortunately, it seems as if Apple may have screwed up their implementation of IndexedDB - and screwed it up bad. Like real bad.
Raymond Camden, IndexedDB on iOS 8 - Broken Bad

Nolan Lawson kept a comprehensive list of the show-stopping issues that plagued WebKit's early IndexedDB implementation. In 2015, he summarized:

IndexedDB was proposed more than five years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn’t release IndexedDB until mid-2014, and when it did, it unveiled a bafflingly incompetent implementation that was so bad, it’s been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari’s version and fall back to WebSQL.)
Nolan Lawson, Safari is the new IE, 2015

Since WebKit happily reported IndexedDB was supported, any site that used feature detection broke. Developers were forced to fall back to things like UA sniffing in order to work around the issue.

Sadly, this wouldn't be the last time WebKit suddenly, completely broke existing websites and later even leaked user data via their IndexedDB implementation.

Read more:

• Safari is the new IE
• Safari is the new IE 2: Revenge of the Linkbait
• IndexedDB on iOS 8 - Broken Bad

2015 - 100vh (100% viewport height) means a different thing in mobile Safari to everywhere else

When working with Viewport Units there’s this longstanding and extremely annoying bug in Safari on iOS where it does not play nice with the vh unit. Setting a container to 100vh for example will actually result in an element that’s a wee bit too tall: MobileSafari ignores parts of its UI when calculating 100vh.
Apple/WebKit’s stance is that it works as intended, although it’s not what I (and many other developers) expect. As a result we have to rely on workarounds.
Bramus van Damme, 100vh in Safari on iOS

Later, Chrome and Firefox would reluctantly adopt the same behavior so all browsers would at least behave consistently. Attempts to reach out to WebKit and discuss better solutions were apparently ignored by WebKit.

Developers had to resort to workarounds, hacks and buggyfills to get Safari (and later Chrome and Firefox) to behave correctly. Eventually, Matt Smith came up with the pretty elegant -webkit-fill-available solution - but this didn't play nice with Chrome, requiring an extra @supports guard.

It wasn't until recently, when the svh, lvh and dvh units landed in all major browsers, that this issue was finally resolved. It's telling that it was not anyone on the Safari team who came up with a solution. They completely intentionally broke the 100vh unit, then ignored the issue for 4 years, and when an independent developer pitched (what would become) the new CSS units, it were the Chrome and Firefox teams who responded and put it on the agenda.

Read more:

• Viewport height is taller than the visible part of the document in some mobile browsers
• CSS: Watch out for 100vh height in mobile browsers
• Avoid 100vh On Mobile Web
• 100vh in Safari on iOS
• CSS fix for 100vh in mobile WebKit

2016 - <body /> with overflow:hidden CSS is scrollable on iOS

The ability to block and/or control scrolling is essential for building advanced user interfaces like popups, bottom sheets, sidebar navigation, etcetera. This Interop proposal goes into more detail about the issue(s) and why they are important.

WebKit, especially on iOS, has had a long history of bugs related to (over)scrolling. Once more, web developers tried to hack their way around the issue, but these solutions were often brittle and never really completely solved the problem - or introduced some other limitation or unwanted behavior.

It took Apple 3 years to fix the initial bug but it didn't take long for someone to notice that they forgot to fix it for installed web apps. Instead of picking it up, WebKit requested that someone file a new bug on this case. Unfortunately, nobody did until 2020. Apple confirmed the new bug and added an internal rdar link - and then, for 6 months, nothing happened (the ticket still has the status NEW). A new ticket was filed in 2021 which was eventually picked up. It took at least another year and 4 months to get fixed.

Even now, there are scenarios (240860, for example) where scrolling is not prevented when overflow: hidden is set on <body /> - so this bug is still not completely resolved.

Read more:

• Extend Scrolling to cover Body Scroll Issues

2017 - Safari incorrectly blocks localhost as mixed content when accessed from an HTTPS page

According to spec, localhost should always be treated as Potentially Trustworthy. Chrome and Firefox (albeit reluctantly) behave correctly, but Safari does not:

Several popular desktop applications (e.g. Spotify) install a server that binds to a localhost port. The web application (e.g. spotify.com) then uses the localhost server to control the desktop application. In order to work around the mixed-content blocker, the web application connects over HTTPS to a host (e.g. *.spotilocal.com) that simply points to 127.0.0.1
...
This ugly hack suffers from a number of problems: it doesn't work when offline due to DNS resolution failure, it doesn't work through proxies, etc.
...
[ ...] the hack also requires a HTTPS certificate. This means that the private key of the certificate is embedded in the desktop application... (I hear some applications have even resorted to installing a root CA so that they can use a self-signed certificate...)
Birunthan Mohanathas , WebKit Bugzilla #171934 c8 and c9

2018: OS 11.2.2 broke WebAssembly

iOS 11.2.2 broke WebAssembly. This broke parts of Wikipedia, all existing published Construct content, and probably more. Much of the difficulty could have been averted by just turning off WebAssembly, so everything reverted to fallbacks. Instead they left it enabled but broken until the iOS 11.3 release months later. In the mean time Apple provided no meaningful help or support whatsoever. We only got support from a helpful Wikipedia engineer who shared a workaround they discovered.
Ashley Gullen, Safari releases are development hell

Although Apple fixed the issue within days, they took their time shipping it. They broke WebAssembly in 11.2.2, didn't ship the fix in either iOS 11.2.5 ¹ or 11.2.6, but opted to wait until iOS 11.3. Although there was a way to detect the bug and have some fallback, many existing websites that used proper feature detection were left broken for months.

2019: Audio stops playing when standalone web app is no longer in foreground

With iOS 12.3, Apple completely broke background audio for installed web apps. It all worked fine in Safari and 3rd-party browsers on iOS, but as soon as you installed it as a web app, started playing audio and moved the web app to the background (either by switching to the home screen, another app or turning off the display), audio playback would simply stop.

It went unfixed for almost 3 years - and when Apple finally fixed it, they forgot to tell developers. There was no workaround except to prevent Safari from installing the web app.

Imagine if a company like Spotify would have believed Apple's claim that web apps are a viable alternative to native apps distributed through their App Store - their Music Player web app would have been completely, utterly useless without background audio! For three years!

2021 - Scrolling in home screen apps incorrectly latches to document

As WebKit's Simon Fraser summarized:

UIKit has a bug where, if an ancestor scroll view is rubber banding, you have to wait for it to stop before you can scroll the inner scroll view (tracked internally).
Simon Fraser, WebKit BugZilla

This bug basically completely broke scrolling for a few seconds whenever the user overscrolled within any child element (including the one the user just scrolled).

To make matters worse, before overscroll-behavior was finally available in iOS 16, the only way to prevent the rubber band effect on the <body /> was setting position: fixed on it - but that didn't actually prevent the effect, it would only hide it. This invisible animation would still block scrolling on child elements until it was finished,

As mentioned earlier: Trying to work around <body /> with overflow:hidden CSS is scrollable on iOS just meant some other thing would break immediately.

Even overscroll-behavior didn't solve the issue, at least not for installed web apps that use the viewport-fit cover meta viewport value. In this case, scrolling would work fine in regular Safari, even if the user installed the web app - except when the user installed the web app and this meta viewport value was in place.

2021: LocalStorage is broken when a page is open in more than one tab

This will result in data loss on websites, as two tabs will be writing to storage, unaware of each others' changes.
Additionally, the 'storage' event is used for cross-tab communication in Safari, since it doesn't support BroadcastChannel, and this bug breaks that.
Jake Archibald, WebKit BugZilla

The fix took a little over 2 months to land.

While this bug did not (directly) affect Safari on iOS and iPadOS, the workaround would: websites could switch to IndexedDB (which was unaffected) to prevent data loss, only to find it broken just a month later - again.

2021: IndexedDB APIs hangs indefinitely on initial page load

The first indexedDB.open() call made by a page appears to be flaky on first load in iOS 14.6.
Its readyState stays as "pending" forever, and none of the event handlers (including "onblocked") are called.
Simon Taylor, WebKit BugZilla

It's kind of baffling how this wasn't caught before it shipped:

Since this bug is so easy to trigger by just opening a database, it likely affects many other sites as well.
Feross Aboukhadijeh WebKit Bug Tracker

While there was a workaround, existing sites that relied on IndexedDB were broken until the fix was released in iOS 14.7 and macOS 11.5 about a month-and-a-half later.

2021 - Fetch request streaming is implemented just enough to pass feature detection, but it doesn't actually work

Safari half-shipped request streams in fetch, so it passes the feature detect, but doesn't actually support the feature.
Jake Archibald, Twitter

Note: We don't have a WebKit Bugzilla ticket for this one, but we've reached out to Jake. He told us he did submit one, but couldn't provide a link at the time. We will update this post when we have more information.

2021: IndexedDB API information leaks

[...] a software bug introduced in Safari 15’s implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity
fingerprint.com, Exploiting IndexedDB API information leaks in Safari 15

This one was a biggie: Apple's Safari leaked IndexedDB data to other sites. Site isolation is the one thing that browsers are supposed to get right.

Apple did not respond to the bug for 6 weeks, at which point the security researchers who reported the issue felt compelled to disclose it publicly (and maybe shame Apple into action):

The issue was reported to Apple on the 28th November 2021 but after 6 weeks of non-action was publicly disclosed a few days ago.
...
For iPhone and iPad users, the fix can not come too soon. While macOS users can and should use an alternate browser, on iOS all browsers use the Safari web engine, meaning all iPhone users have no mitigation except to stop using the browser on their phone.
mspoweruser.com, After ignoring it for 6 weeks, Apple starts testing fix for major Apple Safari privacy bug that leaks your Google ID

Safari 15.3 fixed the issue, which was released on January 26th 2022 - a patch gap of 60 days.

Minor bugs by Year

While not every bug is a showstopper by itself, the web has suffered a lot from what can only be described as death by a thousand Safari bugs. If developers and users run into issues on sites at every turn, it drags down the entire platform. Accumulated, these issues become showstoppers.

We don't have detailed descriptions for each of them, but hopefully the sheer quantity of things that would break gives a good idea of what web developers have had to deal with over the years.

2008: Focus events for non-input elements behave differently in Safari to every other browser

Clicking on a button in Safari not only does not focus it but also removes focus from a previously-focused element. Instead of fixing this, Apple first spent more than a decade defending it (without testing it, presumably) and has now spent more than two years ignoring it after their theoretical claims about consistency were disproved.
All this while, websites that work everywhere else continue to break in Safari.
Mayank, When will Apple focus on Safari?

Note: WebKit may not actually be going completely off-spec here and they have done some related fixes/changes to improve the situation a bit. That said, I think most would agree that the current behaviour seriously hampers accessibility.

2012: Using border-image with border-style: none is rendered completely wrong

This one took 9 years.

2014: WebKit doesn't calculate padding-top/-bottom: n% correctly

2014: Pointer events should allow for device-pixel accuracy

2014: Support for 120Hz requestAnimationFrame

#TODO: Check fixed/released

2018: Safari 11.1 broke MessageChannels

Safari 11.1 broke MessageChannels in a way that broke Construct, and left us maintaining workarounds for years.
Ashley Gullen, Safari releases are development hell

2018: Some Fetch requests incorrectly completely skip the service worker

2019: PWA in iOS uses old assets after publishing new servicerWorker/assets

The PWA does not have to be "running while a new version of the application is being released" for this bug to manifest. The PWA just needs to be have been installed (added to the Homescreen).
Without the workarounds linked by others in the comments, this bug is a blocker to deploying a PWA on iOS.
Comment

2020: When leaving current scope of PWA, back button incorrectly reads "Untitled"

Unfortunately, there is a bug, where the back button to your PWA shows "◀ Untitled" and not the actual PWA's name or short name
Maximiliano Firtman, iPhone 11, iPadOS and iOS 13 for PWAs and web development

The earliest bug report we could find is from 2020 but Maximiliano Firtman first wrote about it in his coverage of iOS 13, which was released the year before. We reached out to Firtman and he said he did try to bring this to the attention of the WebKit team after writing the article.

Apple, meanwhile, has marked the WebKit bug as INVALID (but were kind enough to create an internal ticket for it which was then ignored for more than 2 years):

I believe the issue is occurring outside of WebKit. Apple internal see rdar://54220296
Smoley, WebKit Bugzilla

2020: Safe-area-inset-bottom still set when keyboard appears

2020: Support for background-attachment: local has suddenly completely disappeared

2021: IntersectionObserver and ResizeObserver fire in incorrect order

The linked ticket is from 2022, but I first ran into this issue in Feb 2021. I think this is how it shipped in Safari 13.1 (2020). I never filed a ticket because I found a ticket that seemed related (which is still not (completely) resolved btw): #196729
Roderick Gadellaa, for this blog

iOS 16.4 included the fix.

2021: Mousemove events fire when modifier keys are pressed, even if the mouse isn't moved

Huh, this is an interesting one. Safari fires a mousemove event on keydown/up if the key is shift, ctrl, alt, cmd etc, even if the mouse hasn't actually moved.
Neither Chrome or Firefox do this. Safari doesn't do it for other keys.
Jake Archibald, Twitter

In Safari's defence, the MouseEvent objects have boolean properties for the state of those keys, so it's kinda sort-of reasonable to fire another event when that state changes.
But yeah, firing mousemove when the mouse didn't move feels weird.
Jake Archibald, Twitter

2020: Safari 14 shipped a broken replaceChildren() method, which caused glitches in Construct.

2021: Appending an element to the shadow DOM in many cases hard crashes the browser process

We assume the fix landed in iOS 14.7 (July 2021).

2022 - WebM Opus support is inconsistent in Safari

On Safari 15.4 on iPadOS 15.4, WebM Opus playback is not detected with canPlayType(), does not play with <audio>, but it does actually work if passed to decodeAudioData.
Ashley Gullen, WebKit Bugzilla

[...] it's unclear if Apple are even working on it, with no clear indication about their intentions since I filed that issue around a year ago.
Ashley Gullen, Safari releases are development hell

2022: Installed web app with viewport-fit cover causes overscroll issues, breaks position fixed and -webkit-fill-available

The overscroll issue was fixed in iOS 16.3, but the ticket was never updated (or assigned to anyone). The other issues that were mentioned in the ticket(s) have not been fixed as of this writing.

2023: iPadOS: Viewport doesn't correctly restore after dismissing software keyboard for installed web apps

2023: iPadOS: window loses focus when dismissing the keyboard, breaks Page Lifecycle API

References

• “Safari releases are development hell”
• “Safari isn't protecting the web, it's killing it”, 2021
• ”Safari is the new Internet Explorer”, 2018
• ”Safari is the new IE”, 2015
• ”IndexedDB on iOS 8 - Broken Bad”
• ”Safari is the new IE 2: Revenge of the Linkbait”
• ”PouchDB 3.0.6: Safari Madness”, 2014