WebAudioPlayer works only after manually triggered action

I’ve been using a WebAudioPlayer on my WebPages to generate sounds, and it’s worked really well, except on one page in particular. If the user clicks on a button on that page, or manually causes a dialog to open, then the WebAudioPlayer works from that point on.

What is it about a button press or web dialog that causes a page to start behaving, and to allow the WebAudioPlayer to play as it should?

I’ve got WebAudioPlayer’s on all my pages, all triggered programmatically, but it’s only the page that has a ton of WebContainers on it that forces me to ‘interact’ with the page before the WebAudioPlayer functions properly. Thanks for any advice.

Many browsers block auto-play, and there are plugins that help fight developers that have weaseled their way past auto-play protection (glaring at you, YouTube).

Mozilla Developer auto-play reference
Chrome Blog’s auto-play policy
Firefox default to block auto-play

Is this page the first page you show by chance? That would fall in line with browser default auto-play protection.

It isn’t the first page loaded, but it is a page that loads without any human interaction. I use cookies to take the user past the login page and loads the page (the one I’m struggling with) where the audio is blocked. If I remove the cookie/auto-login, stop the user on the login page and they have to “click something” to get the next page to load, then the audio plays fine and the page behaves like I’d like it to.

It’s almost as if I’d need to create an event in the Shown Event of the page to simulate a human click…?

Have you tried different browsers? Same result?

Yep, so it has everything to do with blocking auto-play behavior. However, forcing the user to click on something pretty much anywhere on a prior page (or the target page) seems to alleviate the blockage across all platforms.

1 Like