-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Handle promise rejection for sound.play() in preload #2162
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, hit approve too quickly. Couple problems,
- This uses an ES6 feature. Blockly is still written in ES5 for compatibility with older browsers.
- This pull request is against master, it should be against develop.
@RoboErikG thanks, I've fixed those problems. Why doesn't Blockly use Babel? |
@RoboErikG @rachel-fenichel @epicfaace I don't think Babel would fix this particular case. |
@AnmAtAnm so does this now fail differently for older browsers, and in a way that we need to be concerned about? Or is it just that this solution doesn't get rid of the warning in the older browsers? |
In my project, play-request-was-interrupted this is how I solved the problem. |
Any changes to sound need to be tested on all browsers (including IE), iOS, and Android. Sound is a surprisingly immature and inconsistent beast. The current Rube Goldberg method in which Blockly plays sound is a result of playing whack-a-mole until a working solution emerged. Specs and logic are irrelevant, it's all driven by the random implementations of each browser. |
may be like this,check play() method return promise before pause()
|
The basics
The details
Resolves
audio play() called before user interaction #1902
Handle promise rejection for sound.play() in preload. This removes the error, "play() failed because the user didn't interact with the document first."
Test Coverage
Tested on:
Mac OS X
Additional Information