Debugging Safari aka the new Internet Explorer

Debugging Safari aka the new Internet Explorer

·

7 min read

Debugging browser compatibility issues is one of the most painful and dreaded parts of being a front-end dev. If you started your career relatively recently and you never had the "pleasure" to debug the notorious Internet Explorer, consider yourself lucky. The rest of you know what I'm talking about. Some of you might even still have PTSD flashbacks to this day. So there goes your trigger warning.

The rise and fall of the best Chrome downloader

Back in the day, the IE started off as a revolutionary modern browser compared to its then-biggest competitor, Netscape. It was the first browser to implement CSS and introduce dynamic HTML so that pages could be dynamically changed using Javascript. No wonder it quickly became the most used browser. Although the fact that it came preinstalled with Windows probably had something to do with that too. Some even say that was the main source of problems.

Because of its newly gained monopoly (at one point, it had a 95% browser market share), Microsoft just got lazy and stopped adding innovations. Over the next few years, it started to fall behind its newer competitors, Firefox and later Chrome. The bugs and security issues were popping out all over the place. It became slow and started crashing.

When Microsoft finally got around to releasing new versions, things only got worse. Now there were multiple versions of IE to be maintained, each with its own set of unique bugs. And because of its huge market share, there was no way to avoid it. That is if you didn't want to lose a large portion of your user base.

If you had spent X hours developing a slick site that worked perfectly in Chrome, Firefox and Safari, you'd better be prepared to spend X more hours fixing it in all the versions of IE. What was once the best browser, became a front-end dev's worst nightmare and the butt of countless jokes.

The new most hated browser

Luckily, the days of the IE are gone (🪦 RIP June 15, 2022). Microsoft ended the support for the IE in June 2022 and permanently disabled it this February.

However, it looks like Safari is the new challenger to take the spot of the most-hated browser. The idea of Safari being the new Internet Explorer is not new, it started circulating as early as 2015, and there is even a dedicated page to that. And the discussion is still going strong even today, just look at Twitter's #SafariShouldDie hashtag or this recent Reddit thread. But surely Apple has stepped in to do something about it, right?

An apple a day keeps the competition away

Unlike IE, Safari never made it to the top of the list. Currently, it's the second most used browser. Similarly to IE, Safari also comes preinstalled with the operating system, however, Apple took this even step further.

On MacOS you can opt out of using Safari and use whatever browser you want. On iOS and iPadOS, on the other hand, Apple doesn't allow to use of third-party browser engines in apps that browse the web. Even if you download Chrome or Firefox from the Appstore it still has to use Apple's own Webkit under the hood.

One bad apple spoils the whole barrel

The pressure for allowing other browsers on iOS is going on for over a decade now and even resulted in the formation of the Open Web Advocacy initiative, whose main priority is to push for the resolution of the #AppleBrowserBan. Apple argues with security and privacy reasons, that Webkit is more secure than other engines and it wants to prevent the dominance of Chromium.

But calls to allow third-party browser engines are increasing not only from users and developers but also from regulatory agencies. They argue that Apple doesn't provide access to all features and APIs to rival browsers, and thus hinders the competition and innovation on iOS platforms.

Apple's reluctance to fully support functional web apps leads many to believe that it's all just to protect its own Appstore business. If developers could provide a native-app-like user experience in browsers, there would be no reason for them to publish their apps on AppStore which would eat up a part of Apple's profits.

How 'bout them apples

Is Apple finally turning around? Last year they poured more money into the Webkit dev team with a round of new hires and a few days ago they released a big update in Safari 16.4 beta that's finally adding some missing features like push notifications for PWAs.

Although, it's certainly a step forward, for many it's too little too late. Some speculate that other engines coming to iOS will happen soon as both Mozilla and Google are supposedly already working on non-WebKit alternatives for iOS.

Catching the fruit flies

There is no doubt that the development experience in Safari sucks. Even when you steer clear from the experimental features that don't have yet full support across the board. There always seem to appear weird implementation issues that are poorly documented and have no workarounds.

Another problem is that Safari doesn't auto-update and its update is always bundled with an iOS update (on MacOS it's already been unbundled). Apple offers the possibility of updating only to the selected number of its newer devices. Even If the bug gets fixed in a newer version, a significant number of users that have older devices will never get that update. So you always need to maintain and test various versions and devices (Hmm, where have I heard that before? 🤔)

From my personal experience as a professional bug squasher, I can confidently say that the number of weird bugs that I encounter is disproportionately larger in Safari. Here's a selection of some of my "favorite" bugs.

The call to play

A customer reported that in Safari the fullscreen is not activated when the video is clicked. Works fine in all the other browsers. Turns out that Safari just ignores a request to fullscreen when placed inside a play listener:

elem.addEventListener("play", function () { 
    elem.requestFullscreen();
});

Try it out yourself, it still doesn't work (as of today's latest stable version which is 16.3). I've fixed it by adding a click listener instead.

Pretends that webpage is not cached

This one I ran into when debugging a service worker. The PWA was not working in airplane mode and Safari was giving the error:

Turns out you just need to know the secret gesture (duh), which I discovered thanks to this StackOverflow issue. Just hit reload and swipe back and the page appears again.

The PDF saga

A customer reported that their website is not loading when opened from PDF. The website had a link to a PDF that opened in a new window. The said PDF had another link inside that opened a different website, which loaded fine the first time, but on subsequent tries, it was frozen. Not even gifs were playing. However, in the console, everything was looking fine. No error was anywhere to be seen.

After spending hours searching the web and finding exactly zero solutions, I've tried a bunch of random stuff. Turned out that if you opened the said PDF in the same window (instead of the new one) the issue when away. So I changed the target in window.open from _blank to _self and called it a day.

Fast forward a few months. Another customer reported that they cannot return back to their website after opening a PDF link on some iPads. Turned out that when a PDF was opened in the same tab the navigation bar in the PDF viewer didn't appear. You could still swipe to go back but that's less obvious and less user-friendly. Back to square one. I reverted the solution to fix bug no. 2 and decided to deal with bug no. 1 later.

Fast forward a few weeks and iOS 15 was released. Bug no. 1 was fixed. (Yay! I still had to fix it for iOS 12-14 though) Also, bug no. 2 was back 🤬. After additional research finally found a workaround that would work for both issues and that was to use the browser download manager instead of having it opened from the link. I guess you could call that success.

The sweet ending

Even though the user and development experience of Safari is (objectively speaking) nowhere near as bad as it was with Internet Explorer, there certainly are many parallels in their stories.

And while it's true that Chromium dominates the current browser market, that doesn't justify Apple's gatekeeping. Chrome has earned its popularity by responding to its users' and developers' needs. Safari gained its share by eliminating competition from its platforms.

Will Apple's Webkit-only reign finally come to an end as the regulators close in? Or will the new update be enough to keep their monopoly for another 10 years? Has Chromium achieved world browser domination? And what the heck happened to Firefox? Stay tuned to find out in the next episode of Keeping up with the bugs.

And let me know your thoughts in the comments.

Did you find this article valuable?

Support catico by becoming a sponsor. Any amount is appreciated!