Mounir, I think we need to propose new changes to the HTML spec on this.

Specifically, step 5 of "If the new ready state is HAVE_ENOUGH_DATA" should be removed, and we probably need a new flag to indicate that if the element is currently in autoplay. WDYT?

Can't we just expand the paused for user interaction definition? https://html.spec.whatwg.org/multipage/embedded-content.html#paused-for-user-interaction
What step 5 do you refer to? I'd be wary of removing anything from the spec :)

+Philip on his thoughts about the spec.

When the new ready state "HAVE_ENOUGH_DATA", the UA may start an intersection observer and when the video intersects with the viewport, it runs 5 steps.

The step 5 I'm referring to is "Set the autoplaying flag to false."

We should not set the flag at this moment, as the video might go off the viewport and we use the intersection observer to observe the video to be visible again. Then we need to check "if the element is still eligible for autoplay", which will be false if the autoplaying flag is false.

The link to Step 5 is here:
https://html.spec.whatwg.org/multipage/embedded-content.html#ready-states:autoplaying-flag

A bit tricky to find the anchor :)

The "paused for user interaction" is something bit is a weird thing, for something like DVD menus. I'm not sure anyone has implemented it or what it does.

I think the proposed change to the autoplaying flag in #5 would work, together with something that keeps monitoring the video and pauses. The name "autoplaying flag" was already a bit misleading and would become even more so, so this might be an opportunity to rename it.

zqzhang@, can you confirm that Safari iOS already implements this?

They are already implementing this. However the logic is a bit different so we need to keep interoperability in mind.

https://trac.webkit.org/browser/trunk/Source/WebCore/html/HTMLMediaElement.cpp#L7167
See method visibilityDidChange() and updateShouldAutoplay().

In Safari's implementation, they keep track of the reason why autoplay was interrupted, and if it was a visibility change, they resume autoplay.

The visibility signals eventually reach HTMLMediaElement::suspendPlayback() and resumeAutoplaying(). For suspendPlayback(), it calls pause(), which sets the autoplaying flag to false. For resumeAutoplaying(), it resets tha autoplaying flag and calls play(), which I assume is essentially invoking the autoplay logic as if the media has just loaded.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b261e240392eadde78e85ae750d9ba2f51f2239

commit 6b261e240392eadde78e85ae750d9ba2f51f2239
Author: zqzhang <zqzhang@chromium.org>
Date: Wed Feb 15 15:39:09 2017

Autoplay muted video when visible and pause when invisible

In this CL, when a muted video is autoplaying from attribute, we
pause it when it comes off screen.

Intent to implement and ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/UtFM-kndhaI
Spec PR: https://github.com/whatwg/html/pull/2324

BUG= 683141 

Review-Url: https://codereview.chromium.org/2654123002
Cr-Commit-Position: refs/heads/master@{#450707}

[add] https://crrev.com/6b261e240392eadde78e85ae750d9ba2f51f2239/third_party/WebKit/LayoutTests/media/autoplay-when-visible-multiple-times.html
[modify] https://crrev.com/6b261e240392eadde78e85ae750d9ba2f51f2239/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/6b261e240392eadde78e85ae750d9ba2f51f2239/third_party/WebKit/Source/core/html/HTMLMediaElement.h

Verified this issue on M58 - 58.0.3019.0,with this test url -http://xxyzzzq.github.io/sandbox/autoplay/autoplay-muted-visibility-check.html