Open thomasjwebb opened 4 years ago
It's generally the case that many of the APIs defined in js.html are not supported by quite a few browsers. I would suggest using existing polyfills (e.g. https://github.com/shinnn/AudioContext-Polyfill) in such cases, as that means you can write against the standard API and somebody else makes the workaround for you.
Hey @thomasjwebb, yeah it's nuts Safari still uses prefixed WebAudio, presumably it will change in the future but it's been like this for years. Here's the workaround I use
// Amazingly Safari 13 in 2020 does not support WebAudio without a prefix
// this abstract checks for `webkitAudioContext` if `AudioContext` is not available
@:forward
abstract AudioContext(js.html.audio.AudioContext) {
public inline function new(?contextOptions: js.html.audio.AudioContextOptions) {
if (js.Syntax.typeof(js.html.audio.AudioContext) != 'undefined') {
this = new js.html.audio.AudioContext(contextOptions);
} else if (js.Syntax.typeof(untyped webkitAudioContext) != 'undefined') {
this = js.Syntax.code('new webkitAudioContext({0})', contextOptions);
} else {
throw 'Browser does not support WebAudio';
}
}
}
I think we should make this part of the standard library externs because it'll be a few years until this work around isn't needed
Relevant bug on WebKit: https://bugs.webkit.org/show_bug.cgi?id=204719
Since Safari still uses the webkit prefix,
new AudioContext()
fails in Safari. See a crude workaround I used to illustrate the nature of the issue.