Updated tests ... web-platform-tests/wpt#36122

To make this change in Chromium we should do analysis of the compatibility impact and announce a deprecation.

It looks like requiring transient activation is not a normative requirement for the <video> tag. I am not familiar with which browsers enforce this requirement. One data point is that NoSleep.js recommends wrapping the call to their library in an input handler. I assume that is because it falls back to using a <video> element and some browsers require user activation to play a video (or to take a wake lock while playing video).

It looks like requiring transient activation is not a normative requirement for the

Sorry, I wasn't very clear. The transient activation aspect I was referring to was the act of pressing the play button.

One data point is that NoSleep.js recommends wrapping the call to their library in an input handler. I assume that is because it falls back to using a

Yes, exactly that. That's to allow the video to play with audio, even though it's silent (Safari detects it a video that's making noise).

Ok, we've updated WebKit to not consume user activation.

Send a PR with an isolated test web-platform-tests/wpt#36152

@reillyeon, wrote:

To make this change in Chromium we should do analysis of the compatibility impact and announce a deprecation.

Ok, no problem. WebKit will probably ship requiring transient activation. I think we are willing to take the compat hit as otherwise we feel the API might be too easy to abuse.

Closing based on @anssiko comment #326 (comment)

Can someone please take this up though? 🙏

Is WebKit open to switching to a sticky activation model? Chromium's metrics look better for that and it means that a site can reacquire a lock if it had one before but lost it due to visibility changes.