Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to catch sound play errors when using AudioTag #590

Open
josalmi opened this issue Aug 27, 2018 · 3 comments
Open

Unable to catch sound play errors when using AudioTag #590

josalmi opened this issue Aug 27, 2018 · 3 comments

Comments

@josalmi
Copy link
Contributor

josalmi commented Aug 27, 2018

This Issue is about a bug in the API:

Sound can only be played as a response to user interaction like click event and if you fail to do so browsers will throw errors at you. Quoting from https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play

The HTMLMediaElement.play() method attempts to begin playback of the media and returns a Promise which is fulfilled when the playback has been successfully started, and which is rejected if playback fails to begin for any reason (such as permission issues or other problems).

It seems that Phaser expects .play() to always succeed as can be seen here: https://github.com/photonstorm/phaser-ce/blob/master/src/sound/Sound.js#L721 and it would be nice to have a way to catch this. If we were able to catch this error we would be able to ask the user to interact with the game rather than failing silently as it does now. Also the game keeps reporting that the sound is playing.

@josalmi josalmi changed the title Unable to catch sound play errors when using WebAudio Unable to catch sound play errors when using AudioTag Aug 27, 2018
@josalmi
Copy link
Contributor Author

josalmi commented Aug 27, 2018

This could also affect WebAudio playback after Chrome 70: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

@samme
Copy link
Collaborator

samme commented Aug 27, 2018

We're a bit stuck since Phaser also supports browsers that don't return a Promise.

I think the idea is that you could check game.sound.touchLocked before trying playback.

We could either

  • Store the result of play() in a new property, audioTagPlayPromise; or
  • Use the Promise for two new Signals, audioTagPlayStarted and audioTagPlayFailed

@nazimboudeffa
Copy link

nazimboudeffa commented Sep 9, 2018

Do I have to use the play(...) function and don't care about if it throws an error or not or does someone have an example on how to catch an error in js ?
I think this way wa have to catch the errors of all the function in the framework

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants