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

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.

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

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

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?

(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?

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.

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.

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

Sure! Thanks to Tom for the initial work.

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

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

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

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

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

Fixed build bust and WPT expectation for that file.

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

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

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

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

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

(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.

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!

That sounds better, thanks 👍

Fixed!

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.

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).

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.

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.