I imagine that accidental unfair scheduling is to blame here: that the audio processor is keeping things busy in such a way that Firefox isn’t getting its “hey, this tab is closed” message through to kill the event loop. This is definitely a bug in Firefox, and it appears to be consistent across platforms (I’m on Windows, you’re on macOS, someone else is mentioning Android). The patch to fix this is likely to be quite small.
I do notice, that PulseAudio shows me that the audio stream from Firefox is labelled "AudioCallbackDriver", which is unusual: most Firefox audio streams are labelled "AudioStream". I think this is a little-tested feature in Firefox at this point. Somehow it also manages to activate the speech (espeak) dispatcher too.
With FF mobile on Android I still had ongoing sound after closing
FF completely (at least as far as I know) and I had to reboot my phone.
It's quite concerning that websites are able to do this. While
it is the browsers fault to support all that javascript crap I
think this is also a bug in Android.
> It's quite concerning that websites are able to do this.
They've been able to do this for a long time and for valid reasons (think of a PWA audio player, like a podcast app).
Unfortunately this used to get abused very often. I remember seeing bugs in ads that would: stop your Spotify playback (due to how audio apis work on phones), and continue playing in background (again, this is a feature, but often abused). iOS is much better in that regard, with stricter autoplay policies, etc...
What's super concerning is that audio worked even when the page was closed. Once I kill the tab, the entire process should be killed too.
So yeah, it's possible that it's just an FF bug purely because being able to play audio in BG is a valid feature BUT there should be no audio when the tab has been killed. My guess is that from the OS perspective, the tab is still running.
My another guess is that it has something to do with some clever techniques regarding reducing the app size.