Fix safari play() after source change

[alex-barstow]

Description

Programmatically calling player.play() immediately following a source change will fail in Safari (desktop and iOS) if the video element's preload attribute is set to none.

Open the following links in Safari, start playback, then press the "Play new source" button. These samples demonstrate the problem using a vanilla <video> element.

• play() FAILS following source change
• play() SUCCEEDS after calling load() following source change

Expected behavior: the source changes and starts to play.
Actual behavior: playback stalls

One observed effect of this problem is with the implementation of playlists. With preload: "none", playlists, whether configured to autoadvance or click-to-play, do not work in Safari because playback stalls when switching sources.

Note: This bug has apparently been fixed in Safari 11.

Specific additions

Modify the player.play() method so that if it is called while the content source is still changing in Safari, load() will be called before play().

[serv]

I have a similar problem that's happening with Safari 11 for video.js v5.20.3.

In Safari 11 > Preferences > Websites, I have the website set to Never Auto-Play.

When I try to play any content, the videojs pauses the content. I can check this by seeing that videojs triggers pause event.

Do you think this is the same issue? Or should I file another issue.?

[gkatsev]

@serv that's another unrelated issue that's already been addressed as much as we can in video.js. See #4562 and #4582. Also, https://www.brightcove.com/en/blog/2017/09/autoplay is a good overview, I think of the issues.

[serv]

Sorry to resurface this issue one more time.

After reading, https://webkit.org/blog/6784/new-video-policies-for-ios/, I think the problem I am having is coming from this.

If a <video> element gains an audio track or becomes un-muted without a user gesture, playback will pause.

Wouldn't clicking a button, that triggers .play() be sufficient for a user gesture?

I think there's definitely something funky happening with video.js still because jumping to a middle of the track using .currentTime() plays the track successfully, while simply .play() a track immediately triggers a pause.

I am currently using

    "video.js": "5.20.4",
    "videojs-contrib-dash": "2.9.1",
    "videojs-contrib-hls": "5.11.1",

[misteroneill]

We were talking about this issue this morning and @gkatsev's concerns about unintended consequences. We wonder if we ought to make the if condition more specific - to target only those Safari versions that are known to have this issue and only when preload is actually none?

[alex-barstow]

@misteroneill Yup, minimizing the scope makes sense. I'll make the changes.

[gkatsev]

I had a question about DESKTOP_SAFARI_VERSION

[gkatsev]

Maybe this should just be SAFARI_VERSION? on iOS it'll be equivalent to IOS_VERSION?
I.e., if you return IOS_VERSION instead of null from this iife.

[alex-barstow]

Personally I would find it clearer to have IOS_VERSION solely responsible for mobile and DESKTOP_SAFARI_VERSION solely responsible for desktop, rather than a multi-purpose SAFARI_VERSION, but that's just me. Happy to make this change if you want me to.

[gkatsev]

@videojs/core-committers any thoughts?

[ldayananda]

I think having a separate Desktop Safari version would be more clear.

[brandonocasey]

Yeah I think having desktop is better as well

[gkatsev]

Looks like tests are still failing.

[alex-barstow]

Recent changes to Player#play have apparently addressed the underlying issue here, so this PR is no longer necessary. Closing.