Require transient activation to request lock

[marcoscaceres]

Given #326, we should now require transient activation to request a lock. This would match how <video> works, which requires a user to activate "play" to acquire the lock.

[marcoscaceres]

Can anyone come up with any reason to not consume the transient activation? I'm coming up kinda empty.

[geoffreygaren]

Can anyone come up with any reason to not consume the transient activation? I'm coming up kinda empty.

Normally I support consuming transient activation so that a single click on a webpage doesn't turn into a giant explosion of popup windows, prompts, etc.

But in this case I'm not so sure. The downside of doing wake lock and some other thing is not very high. You can't wake lock twice in an annoying way, like you could with a popup window. And I believe this is how many videoconferencing sites will work: They will have some button like "start call", and when you hit that button, they will want to start a video, request media capture, and do a wake lock. Ideally you would not need to click twice to "start call".

[reillyeon]

+1 to @geoffreygaren's video conferencing example. It seems likely that sites will want to combine a wake lock with something else, likely more visual like requesting media capture. The wake lock request shouldn't consume the activation.

[marcoscaceres]

Ok, yes... and that's actually the best use case (non-fullscscreen WebRTC) and one I realize now I've hit a lot.

[marcoscaceres]

Ping. Can we please get this moving again?

[reillyeon]

@marcoscaceres, we have a bit of data from the metrics I added in Chromium issue 1370132 and it appears that about 80% of screen wake lock requests do not have user activation. That appears to make this proposal a pretty big compatibility issue but I tend to agree with you that requiring activation is a decent protection against abuse.

@rakuco, can you draft a specification update which adds an activation requirement and send an "Intent to Deprecate" to blink-dev@ for requesting a screen wake lock without activation?

[reillyeon]

Using sticky activation for this (at least for requests to reacquire a wake lock) was discussed at the WebApps WG meeting at TPAC 2023. Once the charter updates have been approved let's move forward with discussing the particulars here between the two implementations.

[reillyeon]

The proposed more complex behavior is:

1. If the document has transient user activation then allow the request.
2. If the document has previously acquired a wake lock (and thus has sticky activation due to the requirement above) then allow the request.
3. Otherwise, reject the request.

[vinhill]

What is the reasoning behind requiring transient activation?
I can see use cases where a website might want to request a wake lock without user interaction. For example, during intra-site navigation, after a page reload, or depending on user preference. If a recipe page provides a toggle for keeping the screen on, it seems convenient to restore this user choice on successive page visits.

[vinhill]

@rakuco @reillyeon friendly ping about this. We decided to prototype the API in Gecko without requiring transient activation for now.

[reillyeon]

I'm still not 100% sure that any activation is really required but I'm planning to do another experiment to find out how many wake lock requests have sticky activation, since that seems like a more reasonable requirement.

[marcoscaceres]

Sticky activation might be a good compromise here... I know WebKit also has issues with this (I'll have to dig it up), but it still doesn't feel great that a page can prevent the screen from sleeping without some kind of user gesture first.

[marcoscaceres]

Ok, yeah, found it:

https://github.com/WebKit/WebKit/blob/b6b74556b8e6ecc165a8e1edb5fc73cc8e5853c2/Source/WebCore/Modules/screen-wake-lock/WakeLock.cpp#L68-L98

Right, we set a flag that "the wake lock became sticky", which is even better: That way, we still require the user activation, but once the wake lock is sticky, we can reapply it.

That solves for all cases, without the wake lock just being able to piggy back on global sticky activation.

(this is a generally nice concept we should add to HTML as it prevents abuse, while allowing APIs to behave as expected without needing to re-acquire user activation every time... they only need it once)

[smaug----]

So webkit does what was proposed here #350 (comment)
I could live with that, assuming it is web compatible. I think we need some more data on that, unless #350 (comment) already happened.

[reillyeon]

Agreed at TPAC 2024:

• Implement the algorithm in Require transient activation to request lock #350 (comment).
• Lack of activation throws a NotAllowedError.

[smaug----]

There is some web compat risk there, but we'll figure it out once we try the new model.