Chrome M66 desktop user gesture activation

[inear]

In the upcoming version 66 if desktop Chrome (currently stable is at 64), it will behave just like mobile, that creating and playing a WebAudio context needs a user interaction before action. Just dropping this here before the flood of issues filed about sound not working in Chrome. Will be a problem for us developers creating games or experiences that play intros or whatever before the user clicks on anything. Will be a relief for the users that does not need to listen to autoplay-banners.

https://bugs.chromium.org/p/chromium/issues/detail?id=807017

[inear]

Hm, maybe we actually need to update the library. We need to add desktop Chrome to _enableMobileAudio() test I think. I tried to include it and listening for mouseup to trigger it, but onended does not fire for me on the ButterSource-node in Canary (that will become M66 later) when the howler.state is something else than 'running'. Does anyone have a suggestion how to handle this?

[inear]

I had an old version of Howler installed. With the latest I can get the context out of suspended state when next sound is playing, but maybe it's a good thing anyway to add desktop Chrome to the same logic as for mobile when the behaviour is same.

[goldfire]

Someone correct me if I am wrong, but I was under the impression that it wasn't exactly the same behavior as mobile in that any user interaction will unlock the audio rather than needing a sound played in a user interaction. That seemed to be the case in testing in canary, but I may be overlooking something as I haven't had a chance to dig into it too much just yet.

[inear]

Yes, you are right. Tested again, and a click on the window somewhere was enough. Annoying dev-experience though, when debugging with deep-linking into specific parts of cinematic experiences or testing intros. Hello Firefox!

[themoonrat]

Just a use case scenario that you might want to consider @goldfire .... clicking on a link to get to say, a game, is indeed good enough to unlock audio, so in that case it's not like mobile at all.
However
Go to a game, copy the url, open a new tab, and paste that url to get to the game. Audio will now not work. There has not been a user interaction to get to that game, and thus audio won't work. Since this is effectively how bookmarks work, anyone going back to a game via a bookmark will not have audio.

Therefore I think mobile style auto checking & unlocking for desktop is something that is still required within Howler.

[goldfire]

Right, but the first time you interact within the game the audio will unlock, regardless of if audio is playing in that interaction, no? The "auto" unlocking on mobile still requires a user-interaction, so there isn't going to be any way around that unfortunately.

[inear]

It's really problematic if syncing a longer track of audio to stuff that starts animate on page-load. But at least we will start treat mobile and desktop pages the same. Will see a lot more "start" buttons on the immersive internet.

[themoonrat]

If I have an intro screen to click through, which requires a click then yes, it works, because I have my user interaction before I try to play any audio.
If I have no intro screen, so go straight into the game that has background music,, then clicking anywhere on screen doesn't get the music playing.
If I click somewhere on screen that then will cause another sound to be played, then all sound will resume. But this is due to the play function within Howler

            if (self._webAudio) {
                Howler._autoResume();
            }

It's relying on another sound being played to resume the audio, not on a user-interaction

[goldfire]

Okay, if that is the case, we'll want to update the mobile auto-enable (which probably should be re-named now). That is what I was wanting to verify, just hadn't had a chance to look too closely yet.

[themoonrat]

No probs; me seeing this post started a panic about how this effected our 50 odd games!

[inear]

But as @goldfire pointed out earlier, have you tested if we have to actually play a sound on interaction. Maybe just calling _autoResume on click might be enough.

[themoonrat]

Yeps, just calling Howler._autoResume() gets it all working again, no need to play a sound on interaction