|
| 1 | +# RFC 128: Consume user activation |
| 2 | + |
| 3 | +Editor: Marcos Caceres, Apple Inc. |
| 4 | + |
| 5 | +## Summary |
| 6 | + |
| 7 | +Tests in WPT are currently relying on various indirect means to "[consume user activation](https://html.spec.whatwg.org/#consume-user-activation)" [HTML]. |
| 8 | +Some of these means are non-standard in as far as they are not specified to consume user activation, meaning that the tests are inshrining non-standard behavior for conformance purposes. |
| 9 | + |
| 10 | +The workarounds being used are as follows, with several drawbacks: |
| 11 | + |
| 12 | +* Using Fullscreen API: it takes significant time to put an element into fullscreen. |
| 13 | +* Using window.open() and window.close() - non-standard, not mobile friendly. |
| 14 | +* Using Payment Request API - not widely implemented (e.g., not exposed in Gecko). |
| 15 | + |
| 16 | +We also looked at a range of other possible APIs that consume user activation, and found [none to be suitable](https://github.com/web-platform-tests/wpt/issues/36727#issuecomment-1296349964). |
| 17 | + |
| 18 | +## Details |
| 19 | + |
| 20 | +We would like to propose the addition of an async function `test_driver.consume_user_activation()` method that returns a `Promse<boolean>` (representing if the activation was consumed or not). For example: |
| 21 | + |
| 22 | +``` |
| 23 | +const consume = await test_driver.consume_user_activation(); |
| 24 | +``` |
| 25 | + |
| 26 | +The `consume_user_activation()` method can take a `Window` <var>context</var> (which defaults to the current Window object). Allowing consumption to happen at a particular window, if required. |
| 27 | + |
| 28 | +The `consume_user_activation()` method would be implemented via the proposed addition of “[Consume user activation of Window](https://github.com/w3c/webdriver/pull/1695)” to the Web Driver specification. |
| 29 | + |
| 30 | +This prposal has several advantages: |
| 31 | + * it's fast - no opening windows or waiting for fullscreen to enter/exit. |
| 32 | + * it's lightweight - it doesn't create new browsing contexts. |
| 33 | + * it's mobile friendly - as above. |
| 34 | + * it's build for purpose - no more using other APIs to indirectly achieve the desired outcome. |
| 35 | + * It's really simple - it complements `.bless()` and other user activation functionality already available. |
| 36 | + |
| 37 | +[An implementation](https://github.com/WebKit/WebKit/pull/6539) is available in WebKit. |
| 38 | + |
| 39 | +## Risks |
| 40 | + |
| 41 | +None known. |
0 commit comments