5 ms·

OK, this is really weird, but I closed the browser tab with the demo ca. 1 minute ago and can still hear the music. I'm on FF/Big Sur.

faitswulff 6y ago
Same. Had to force quit.
- suprfsat 6y ago
  Had to recycle my macbook
import 6y ago
Same, there is a weird sine wave with high pitch and frequency.
jackewiehose 6y ago
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.
- rpastuszak 6y ago
  > 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.
- pitaj 6y ago
  Did you try "Force Stop" newbie rebooting? I'd think that should work
thomasfromcdnjs 6y ago
(someone should investigate this)
- zaroth 6y ago
  Indeed. Ultrasonic tracking ftw...
chrismorgan 6y ago
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.
- PaulDavisThe1st 6y ago
  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. Not cool.
ComodoHacker 6y ago
Also corresponding process eats more than 1 Gb of memory.
TheRealSteel 6y ago
Can confirm on latest FireFox on Mojave. It went away when I opened and closed a new blank tab.
rpastuszak 6y ago
OK, I submitted a bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1671968 https://bugzilla.mozilla.org/show_bug.cgi?id=1671968
spurgu 6y ago
Same on FF/Catalina, only 10-15 seconds though.

faitswulff 6y ago

Same. Had to force quit.

suprfsat 6y ago
Had to recycle my macbook

import 6y ago

Same, there is a weird sine wave with high pitch and frequency.

jackewiehose 6y ago

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.

rpastuszak 6y ago
> 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.
pitaj 6y ago
Did you try "Force Stop" newbie rebooting? I'd think that should work

thomasfromcdnjs 6y ago

(someone should investigate this)

zaroth 6y ago
Indeed. Ultrasonic tracking ftw...

chrismorgan 6y ago

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.

PaulDavisThe1st 6y ago
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. Not cool.

ComodoHacker 6y ago

Also corresponding process eats more than 1 Gb of memory.

TheRealSteel 6y ago

Can confirm on latest FireFox on Mojave. It went away when I opened and closed a new blank tab.

rpastuszak 6y ago

OK, I submitted a bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1671968 https://bugzilla.mozilla.org/show_bug.cgi?id=1671968

spurgu 6y ago

Same on FF/Catalina, only 10-15 seconds though.