Safari 11 DOMError "AbortError" - Programmatic play prevented

[jesperstarkar]

Probably related to #14 and prevention of autoplay.

Safari 11, both desktop and mobile.

DOMError {name: "AbortError", message: "The operation was aborted."}

once VideoContext run .play() on a cached video element.

[jesperstarkar]

It seems that the attribute muted is needed for Safari 11 (both platforms) to play.

This really feels like a battle we can never win. The <video /> spec is constantly moving.

[huangh0604]

I caught this issue either. Did you find a solution about this?

[PTaylour]

@huangh0604 have you tried supplying a video element with the muted attribute?

I'm not that familiar with the latest autoplay policies. At one point it was the case that unmuted audio playback needed to be initialed by a user gesture.

[199911]

I have a short article about autoplay policy https://medium.com/@sundaykuloksun/video-play-not-working-html5-autoplay-policy-beed81d64ca5

@PTaylour is right, muted video can be autoplay in both desktop and mobile

[PTaylour]

thanks @199911 that's really useful.

@MatthewShotton did videocontext have a workaround for a previous guise of this policy? Or is it just a requirement that ctx.play() (with unmuted video) is triggered by a user interaction on mobile?

[emshotton]

The VideoContext tried to get around this by keeping an internal cache of a number of video elements which all get "activated" when the initial call to ctx.play() is made by a user-gesture: https://github.com/bbc/VideoContext/blob/master/src/videoelementcache.js

These elements then get re-used throughout the VideoContexts time-line by having their src attribute changed as appropriate. This workaround still means you have to have the inital ctx.play() triggered from a user gesture.

Last time i tested this it seemed to work OK on Safari, it's possible a recent changes have prevented this strategy. This guest blog from the Safari team goes into a bit more detail about the current policies: https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/

It looks like you can catch a failed play call by checking the Promise returned from MediaElement.play();. Which suggests a potential work-around for if you want the VideoContext to autoplay is to catch that rejected promise, and present the user with some play controls (somewhat defeating the concept of autoplay, but is better that nothing). I don't believe the VideoContext currently surfaces failed play calls.

[emshotton]

It looks like Chrome is moving to a similar autoplay policy as Safari in the next release: https://www.theverge.com/2018/3/22/17150870/google-chrome-autoplay-videos-sound-mute-update

[hktalent]

me too

[Error] Unhandled Promise Rejection: AbortError: The operation was aborted.

fixd: https://developers.google.com/web/updates/2017/06/play-request-was-interrupted

[PTaylour]

Thanks @hktalent, I'll take a look at the fix.

[susiwen8]

Hello @PTaylour, Do you have any solution on this? I have check the doc that provided by @hktalent , but I did't work for me.

[yakca]

Hi @susiwen8 - the best options I see at the moment are to either prompt the user to interact to start video, or to autoplay the video muted as part of its attributes, for example:

var videoNode = videoContext.video("../assets/introductions-rant.mp4", 0, 4, { loop: true, muted: true, autoplay: true });

With the Chrome policy on autoplay that has been active since April 2018, any workaround would likely be temporary and circumventing intended browser behaviour.

Separately, I will look into adding some documentation around autoplay. I think it's best we move on from this rather old issue and acknowledge the landscape for autoplay video has changed since VideoContext was originally written.