You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where possible (specifically, for starting, stopping, pausing, and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, for listing, enabling, and disabling text tracks, and for muting or changing the volume of the audio), user interface features exposed by the user agent must be implemented in terms of the DOM API described above, so that, e.g., all the same events fire.
This means that e.g. clicking on the "play" button of a media element's controls UI, the play method should be called, so that all the events are fired.
However this method does return a Promise, which in this case is created out of the magical user interaction world and can't be acted upon from scripts. This becomes problematic when this Promise rejects, which is the case if the loading of the media is aborted. In this case, the rejected Promise will be observable in the unhandledrejection event, even though it didn't came from any script on the page. https://jsfiddle.net/aomxhpu6/
Currently only Firefox follows the specs here, while Chrome and Safari do not expose the rejected Promise, but I wonder if it wouldn't be better to lean on Chrome and Safari's behavior instead.
The text was updated successfully, but these errors were encountered:
What is the issue with the HTML Standard?
In https://html.spec.whatwg.org/multipage/media.html#user-interface it is said
This means that e.g. clicking on the "play" button of a media element's controls UI, the
play
method should be called, so that all the events are fired.However this method does return a
Promise
, which in this case is created out of the magical user interaction world and can't be acted upon from scripts. This becomes problematic when this Promise rejects, which is the case if the loading of the media is aborted. In this case, the rejectedPromise
will be observable in theunhandledrejection
event, even though it didn't came from any script on the page. https://jsfiddle.net/aomxhpu6/Currently only Firefox follows the specs here, while Chrome and Safari do not expose the rejected
Promise
, but I wonder if it wouldn't be better to lean on Chrome and Safari's behavior instead.The text was updated successfully, but these errors were encountered: