1791079 - Add navigator.userActivation API to query user activation state

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement, P1)

Description

[Mustaq Ahmed]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Steps to reproduce:

We have seen general interest about this API [1], mainly for sake of WPTs for user activation (which otherwise have to rely on the behavior of dependent APIs like popup or fullscreen).

Note that this is about only the navigator interface part of the state propagation discussion [2]. Here is the PR to the HTML spec [3] for that interface.

[1] https://github.com/whatwg/html/pull/4009#issuecomment-542363760
[2] https://github.com/whatwg/html/issues/1983
[3] https://github.com/whatwg/html/pull/8254

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

I wonder this should have gone https://testutils.spec.whatwg.org/ if this is for tests.

Comment 4

[Simon Pieters [:zcorpan]]

See https://github.com/dtapuska/useractivation#motivation , it's not just for tests.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

See also the HTML spec for details:
https://html.spec.whatwg.org/multipage/interaction.html#the-useractivation-interface

All browsers except Firefox have it implemented so this is a cross-browser compat issue:
https://developer.mozilla.org/en-US/docs/Web/API/UserActivation#browser_compatibility

We would also like to see this API for our WebDriver BiDi implementation. Which priority might this implementation get?

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #5)

See also the HTML spec for details:
https://html.spec.whatwg.org/multipage/interaction.html#the-useractivation-interface

All browsers except Firefox have it implemented so this is a cross-browser compat issue:
https://developer.mozilla.org/en-US/docs/Web/API/UserActivation#browser_compatibility

We would also like to see this API for our WebDriver BiDi implementation. Which priority might this implementation get?

Hi Henrik, it's passed the strategic review and scheduled for H2. Do you have more specific timeline that we should try to align better?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thank you for the information Hsin-Yi! No, this is totally fine and we can temporarily mark the test as expected fail until the navigator.userActiviation support has been added. Instead we want to add another test that actually checks the functionality when its enabled and which doesn't use this API.

Comment 8

[Tom S [:evilpie]]

Attachment: Bug 1791079 - Implement User Activation API

Comment 9

[Tom S [:evilpie]]

This patch doesn't pass all WPT html/user-activation, but that seem more like an implementation issue that is unrelated to the API. e.g. propagating across frames or something like that?

It's also a bit annoying that we already have a class UserActivation that has a bunch of static functions like IsHandlingUserInput. Right now I just turned that class into the DOM class and kept the static methods.

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi :canadahonk, please help us drive this cross the completion line, based on Tom's WIPs. Thank you and thanks Tom!

Comment 11

[Oliver Medhurst [:canadahonk]]

Sure! Thanks to Tom for the initial work.

Comment 12

[Oliver Medhurst [:canadahonk]]

Also, the chrome-only document.hasBeenUserGestureActivated/document.hasValidTransientUserGestureActivation should be able to be replaced with this new API if wanted to clean up.

Comment 13

[Oliver Medhurst [:canadahonk]]

Standards issue: https://github.com/mozilla/standards-positions/issues/838

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7c84c5fc7d00
Implement User Activation API r=dom-core,webidl,saschanaz,edgar

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42395 for changes under testing/web-platform/tests

Comment 16

[Sandor Molnar[:smolnar]]

Backed out for causing mochitest process crashes at @ RefPtr<mozilla::dom::WindowContext>::operator->

Backout link: https://hg.mozilla.org/integration/autoland/rev/6ce0530618383c2dbe76362aed3b796bb31749ec

Push with failures

Failure log -> PROCESS-CRASH | MOZ_ASSERT(mRawPtr != nullptr) (You can't dereference a NULL RefPtr with operator->().) [@ RefPtr<mozilla::dom::WindowContext>::operator->] | layout/base/tests/mochitest.ini

Comment 17

[Oliver Medhurst [:canadahonk]]

Forgot to add a null check, sorry. Fixed and will reland.

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73919dbff272
Implement User Activation API r=dom-core,webidl,saschanaz,edgar

Comment 20

[Narcis Beleuzu [:NarcisB]]

Backed out for bustages on Navigator.h

Backout link: https://hg.mozilla.org/integration/autoland/rev/0b23e7aba254cde68dd0c62c61f4afacc358f4cb
Log link: https://treeherder.mozilla.org/logviewer?job_id=431633130&repo=autoland&lineNumber=12644

Please also check this fail on element-ready-check-containing-iframe.html

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 22

[Oliver Medhurst [:canadahonk]]

Fixed build bust and WPT expectation for that file.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fba49989dde6
Implement User Activation API r=dom-core,webidl,saschanaz,edgar

Comment 24

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/fba49989dde6

Comment 25

[Dianna Smith [:diannaS]]

:oliver is this something worth mentioning in the Fx120 release notes?

Comment 26

[Oliver Medhurst [:canadahonk]]

Yes, I was going to flag relnote on Monday :)

Comment 27

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 28

[Oliver Medhurst [:canadahonk]]

Release Note Request (optional, but appreciated)
[Why is this notable]: New web API (navigator.userActivation)
[Affects Firefox for Android]: Yes
[Suggested wording]: The User Activation API has been added, allowing JavaScript to check if the user currently is or has been active with navigator.userActivation.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/API/UserActivation

Comment 29

[Dianna Smith [:diannaS]]

Added to Fx120 nightly release notes https://www.mozilla.org/en-US/firefox/120.0a1/releasenotes/

Comment 30

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

(In reply to Oliver Medhurst [:canadahonk] from comment #28)

check if the user currently is or has been active with navigator.userActivation.

Sounds a bit confusing to me, it's not really about the user but about the interaction with the page, right? "The user currently is active" sounds like it's tracking physical movement through camera to me.

Comment 31

[Oliver Medhurst [:canadahonk]]

Sorry, good point, better wording might be "...the user currently is or has been active with the page (clicking, etc) with navigator.userActivation". Dianna would you mind updating this to avoid confusion later? Thank you!

Comment 32

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

That sounds better, thanks 👍

Comment 33

[Dianna Smith [:diannaS]]

Fixed!

Comment 34

[Hamish Willee]

FF120 MDN docs for this can be tracked on https://github.com/mdn/content/issues/29778. Compatibility work already done.

The original API in the explainer was quite different and centered around a use case where a page might want to decide if it should allow an iframe to expand itself by checking if the user had interacted with the iframe. While the docs UserActivation and Navigator.userActivation accurately reflect the specification, they have lost information about use cases where this might be something you want to do - i.e. it is only "if you want to programmatically check for user activation". I think it is useful to expose use cases in docs.

So:

1. Is the explainer use case still one of interest? If so, would this be done by a message from the iframe, and then doing something like the following to check the frame activation?

    const iframe = document.getElementById('myFrame');
    let userActivation = iframe.contentWindow.navigator.userActivation;
   

   Or is it expected that you'd just check the parent frame navigator and it would show activation of the contained frame too? I.e. how is this really expected to be used now? (example code would be nice!)
2. Are there any other main use cases we expect this to be used for?
3. Some of the WPT tests pass for Chrome and not for Firefox, and visa versa https://wpt.fyi/results/html/user-activation?label=master&label=experimental&aligned
   • are these indicative of off-spec behaviour or Firefox bugs?
   • is there something going on here that needs to be captured in docs?

Thanks.

Comment 35

[Oliver Medhurst [:canadahonk]]

Thanks for the MDN work! To answer your questions:

1. Not really sure to be honest, the explainer is quite outdated. I don't think so. I think the below is the most common use by far.
2. Some sites use this to check if the user is active and open a popup, play video/audio, etc if so. This is to avoid popup blockers or ensure they are allowed to play video/audio, etc.
3. These are (niche) webdriver bugs, they do not occur in regular usage and do not need to be documented.

Please also note the includeUserActivation option for postMessage is not implemented or supported as it is non-standard (as of now).

Comment 36

[Hamish Willee]

Thanks very much Oliver! Very useful to know all this because it means the current docs are largely sufficient. FYI only - work for this done and in review.

Comment 37

[Mustaq Ahmed]

Just wanted to add two points from the Chrome side:

• The HTML spec is now the source of truth for this API: https://html.spec.whatwg.org/multipage/interaction.html#the-useractivation-interface
• This API has been proposed for Interop 2024 focus, we will love to see Mozilla's commitment there: https://github.com/web-platform-tests/interop/issues/428.