Remove all references to webkitAudioContext. NFC

[sbc100]

We were only keeping this code around to support older safari versions. However the oldest safari version we currently support is 14.1, which is the first release to support the modern AudioContext object.

There is some confusion only about Safari 14.1 was release as part of iOS 14.5. As far as I can tell Safari 14.1 is the version we should be caring about for AudioContext.

See https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/

[sbc100]

I asked Gemini: Explain the confusion between Safari 14.1 and 14.5:

The Confusion

Apple caused confusion by mixing browser and OS numbers.

• Safari 14.1 was the actual browser version.
• iOS 14.5 was the iPhone operating system.

The Mix-up

• Apple shipped Safari 14.1 inside iOS 14.5.
• People blended the numbers together by mistake.
• There is no actual browser called Safari 14.5.

Why It Mattered

• Analytics: Code confused OS versions with browser versions.
• Features: New web tools launched on both systems simultaneously.
• Updates: Desktop got Safari 14.1.1 while mobile got iOS 14.5.1.

Are you looking for a specific feature or a bug fix from this version?

[kripken]

Hmm, but iOS version is how versions are reported for Mobile Safari? That is, caniuse and other websites do refer to a 14.5 browser on iOS. Shouldn't we use the same version numbers as them? E.g.

https://caniuse.com/?search=AudioContext+constructor

[sbc100]

But iOS 14.5 run Safari 14.1, effectively: https://firt.dev/ios-14.5/ : "iOS 14.5 brings the new Safari 14.1 to PWAs and the Web Platform".

Basically, by saying the we don't support browser older that safari 14.1 (which we already say in out feature_matrix.py) we are effectively already saying we don't support iOS prior to 14.5, I believe.

[sbc100]

Note: Safari 14.1 and iOS 14.5 have the same release date, so the cutoff is the same.

[sbc100]

Apparently the UserAgent string for iOS safari looks like this: Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1

Note that the Safari version is shown in the Version/XXX part. In this example this is iOS 18.6 running Safari 26.

I'm fairly sure that iOS 14.5 will report Version/14.1. Our version checking code only looks at the Version/XX and not the iOS version:

emscripten/src/minimum_runtime_check.js

Line 45 in c407b75

var currentSafariVersion = userAgent.includes("Safari/") && !userAgent.includes("Chrome/") && userAgent.match(/Version\/(\d+\.?\d*\.?\d*)/) ? humanReadableVersionToPacked(userAgent.match(/Version\/(\d+\.?\d*\.?\d*)/)[1]) : TARGET_NOT_SUPPORTED;

[sbc100]

Here is report of the exact UserAgent string used in iOS 14.5: AzureAD/microsoft-authentication-library-for-objc#1409 (comment)

Mozilla/5.0 (iPhone; CPU iPhone OS 14_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1

Prior to iOS 14.5 the safari version was lower the 14.1, so we already do not support iOS older that 14.5, at least not since #26677.

[kripken]

I'm fairly sure that iOS 14.5 will report Version/14.1.

Seems reasonable, yes, but what do you think about my point about caniuse? My thinking is that the version numbers people use in practice are likely coming from there. That is, a developer checks on caniuse and sees version X seems right, and they insert that as the version number in emscripten. So us following caniuse, rather than the technically-more-correct internal WebKit version, seems safer to me?

[sbc100]

I'm fairly sure that iOS 14.5 will report Version/14.1.

Seems reasonable, yes, but what do you think about my point about caniuse? My thinking is that the version numbers people use in practice are likely coming from there. That is, a developer checks on caniuse and sees version X seems right, and they insert that as the version number in emscripten. So us following caniuse, rather than the technically-more-correct internal WebKit version, seems safer to me?

I'm not quire sure what you are proposing a solution though. Right now we have MIN_SAFARI_VERSION that corresponds the the Safari / Webkit version and not the iOS version. It corresponds the Verion/XXX reported by the user-agent.

Should we create a new MIN_IOS_VERSION (which would currently have a minimum of 14.5 to match the current MIN_SAFARI_VERSION)?

[sbc100]

In any case the status quo in emscripten does not match what what you are saying.

If I say MIN_SAFARI_VERSION=4.1 today that does not mean that the output will run on iOS 4.1. In fact it will fail the check in minimum_runtime_check.js because the Safari version in iOS 4.1 is 4.0.4 and we do not support this version safari anymore.

This PR is just a continuation of the status quo IIUC. What you are suggesting (using iOS version numbers) would be a departure I think,.

[kripken]

Ok, fair enough. I worry slightly that users could get confused by this (if all they know is caniuse), but these are versions from 5 years ago so maybe the risk is low. And the precise definition of the terms is as you say.