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.

[domenic]

I don't really understand TestUtils vs. WebDriver, but yeah, seems reasonable to me.

[marcoscaceres]

oh! TestUtils is this spec:
https://testutils.spec.whatwg.org

Given the discussions we've had elsewhere, I would argue that this is generally useful for web developers doing automated testing because it allows them to test for situations where transient activation has expired (and they many need to recover somehow). Thus, this fits into the "Web Driver" bucket, instead of the "browser vendor" bucket.

@jgraham, @EdgarChen, would you agree?

[marcoscaceres]

I slapped together a quick PR:
w3c/webdriver#1695

Would appreciate any feedback there.

[EdgarChen]

Doesn't have strong opinion on TestUtils vs Webdriver, just learn about TestUtils few days ago and share a possible altertive here :)

[marcoscaceres]

Ok, implemented test_driver.consume_user_activation() for WebKit's test runner (not Safari Driver yet!): WebKit/WebKit#6539

It makes the tests super nice 😍 (plus WebKit now passes a lot more tests ✅):

consumed = await test_driver.consume_user_activation();

Everyone ok with making this a thing?

[mustaqahmed]

This would be a great complement to test_driver.bless() and test_driver.click(). Thanks, 👍

[gsnedders]

Ok, implemented test_driver.consume_user_activation() for WebKit's test runner (not Safari Driver yet!): WebKit/WebKit#6539

It makes the tests super nice 😍 (plus WebKit now passes a lot more tests ✅):

consumed = await test_driver.consume_user_activation();

Everyone ok with making this a thing?

This per our normal process should require an RFC.

[marcoscaceres]

@gsnedders, ok cool. I can draft that up for WPT.

For Web Driver, I followed:
https://github.com/w3c/webdriver/#contribute

However, for the tests... I don't know any Python... I can try to copy/pasta 🍝 my way to success, but if anyone wants to help me with that, it would be massively appreciated. 🙏

[marcoscaceres]

Hey everyone, I put together the RFC:
web-platform-tests/rfcs#128

Would love you feedback and, if you agree, show of support there.