the gesture that started this audit registered as a real user activation
Check id user-activation-vs-interaction
What an ordinary browser yields
Contextual only: hasBeenActive should be true, because the audit is reachable only by pressing a button and pressing a button grants activation. Not scored — see above.
What a detector infers
This audit only runs when you press the Run button, and pressing a button is exactly what grants user activation — by pointer, by Enter or Space on a focused control, or through a screen reader, all of which travel the browser's real input pipeline. So by the time the check executes, a genuine gesture has necessarily happened and navigator.userActivation.hasBeenActive must be true. The flag is sticky for the window's lifetime, so nothing that happens afterwards can take it away. What makes this worth asserting is the precise thing the flag distinguishes: element.click() and dispatchEvent() do NOT grant activation, because activation is a property of the input pipeline rather than of the event object. A run that reaches this line with hasBeenActive still false was therefore started by script, not by a person. There is a candid story attached: during development this check read false, and the reason was that the page was being driven by synthetic onClick calls to test it — the check was working exactly as designed and catching its author. Note what it does NOT claim. CDP's Input.dispatchMouseEvent — the mechanism under Puppeteer and Playwright — injects at the browser's input pipeline above the renderer, so it DOES grant activation and passes this check. Like Event.isTrusted, this separates page script from the input pipeline; it says nothing about who is at the other end of that pipeline. This row is CONTEXTUAL and never scored, and the reason is a piece of honesty worth recording. The reasoning above says a real click always grants sticky activation, so hasBeenActive must be true by the time this runs — and that is probably right. But it was never verified: no tool available could produce a genuine human click, so every measurement taken showed the FAILING value and not one showed the passing one. A scored check whose pass case has never been observed is a check that fires on every real visitor if its reasoning is wrong, which is the worst thing this page could do. So it reports and explains rather than counts, until a human click is confirmed to turn it true. The row is also N/A on Gecko and WebKit, where navigator.userActivation does not exist at all.
How to resolve it
If you are driving this page programmatically, note that a JavaScript-level .click() or a dispatched event never grants activation — the browser's input pipeline does. CDP-injected input satisfies this check trivially. There is nothing to fix for a person who pressed the button.
Read in the wild by
Kasada
Reads both halves of navigator.userActivation.
user_activation_is_active, user_activation_has_been_active
Kasada ips.js teardown — the full 427-probe listEvery attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Automation surface
- document.hidden agrees with document.visibilityState
document-visibility-coherencedocument.hidden and document.visibilityState are two views of one piece of state, and the specification defines the first in terms of the… - navigator.plugins is a real IDL collection, not a JavaScript object
plugins-idl-index-wraparoundA real navigator.plugins is a PluginArray — a C++-backed IDL collection — and its indexed getter runs the Web IDL unsigned-long conversion… - navigator.storage quota is the same in the window and a same-origin worker
storage-quota-worker-vs-mainnavigator.storage.estimate().quota describes one storage partition, and a same-origin worker shares that partition — a single QuotaManager… - performance.timeOrigin + performance.now() reconstructs Date.now()
clock-origin-coherenceA page has two clocks. performance.timeOrigin is the wall-clock moment its timeline began; performance.now() is the monotonic time elapsed… - user activation only ever appeared after a real input event
activation-without-inputThe row above this one reads navigator.userActivation once and expects it to be true, because the audit is reached by pressing a button. - the clicks this page received were real clicks
interaction-click-trustEvent.isTrusted is set by the engine when it dispatches an event it generated itself, and it cannot be set from script - a constructed… - every keypress had a keydown behind it
interaction-keypress-without-keydownThe UI Events spec generates keypress as the DEFAULT ACTION of a keydown - it is not an independent event, it is what a keydown does when it… - key events named the key they carried
interaction-key-identity-populatedA keypress the engine generates names the character it is delivering in .key.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Automation surface checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Automation surface — the family user-activation-vs-interaction belongs to.