Figure out a means to "consume user activation"

[marcoscaceres]

Tests in WPT are currently relying on various indirect means to "consume user activation". Some of these means are non-standard, meaning that the tests are inshrining non-standard behavior for conformance purposes.

These workarounds are:

• using fullscreen API
• using window.open and window.close
• Using Payment Request API

The are not interoperable solutions. We should come up with something better.

Some proposed straw-persons:

• A web driver API to consume user activation
• A method on UserActivation itself to consume user activation.
• Something else???

[domenic]

Why are those not interoperable? At least PaymentRequest calls "consume user activation" in its spec, and per the WebDex link I posted, so do several others.

[marcoscaceres]

per the WebDex link I posted

Thanks... this is what I found:

• The Storage Access API - not implemented in Chrome. Requires explicit user permission denial, and wouldn't work for same-origin.
• The Capture-Handle Actions Mechanism, not implemented in WebKit (unsure if we plan to support that). Doesn't seem to be in Firefox either.
• Capability Delegation, WICG spec. Not widely implemented.
• Close Watcher API - not implemented by anyone.
• Payment Request API 1.1 - No Gecko support.
• Secure Payment Confirmation - Chrome only. No signals of support from other vendors.
• Web Share API - can be OS modal, so can't be cancelled by web driver. .share() operation can't be cancelled via API.
• Multi-Screen Window Placement - Chrome only.

Generally speaking, anything that requires user permission prompts probably can't be used, because those are usually modal (and non-cancellable) on mobile browsers.

So, a third option is seeing if there is a useful intersection in the above that covers all engines (and it would be a somewhat ugly hack). However, I'm not seeing anything very viable from the above.

[marcoscaceres]

@domenic, @mustaqahmed, what's the resistance (if any) to adding .consumeUserActivation()?

Even if we get agreement that .requestFullscreen() will consume it, .requestFullscreen() is computationally extremely expensive: it can take upwards of a second to rquestFullscreen().then(.exitFullscreen()). This ends up adding a lot of overhead to testing infrastructure, both for implementers and developers.

Having a sync consumeUserActivation() would solve for the above. Similarly, with window.open().close(), which is not very mobile friendly and also takes a lot of computing power... can make a sustainability argument here too 🌲.

[EdgarChen]

Some proposed straw-persons:

• A web driver API to consume user activation
• A method on UserActivation itself to consume user activation.
• Something else???

Or a method on TestUtils to consume user activation.

[marcoscaceres]

Sorry if this is a silly question, but wouldn't TestUtils still also just rely on a one of the "hacks" above (unless Web Driver consumed it)?

[domenic]

what's the resistance (if any) to adding .consumeUserActivation()?

It doesn't solve any user- or web-developer facing problems. Test-only utilities should be done via Web Driver, not via exposed APIs.

[marcoscaceres]

Ok, I agree.

So we have consensus that Web Driver is the way to go then?
w3c/webdriver#1691

I can try to put together a PR for that.