the clicks this page received were real clicks
Every click on the gate trusted. A keyboard-activated click is trusted too and is reported, not penalised (severity: warn).
What a detector infers
Event.isTrusted is set by the engine when it dispatches an event it generated itself, and it cannot be set from script - a constructed MouseEvent is false, and element.click() produces a synthetic click that is false too. So a click arriving at a listener with isTrusted false did not come through the browser's input pipeline, whatever produced it.
What this deliberately does NOT score is detail, clientX or pointerType: pressing Enter or Space on a focused button produces a trusted click with detail 0, clientX 0 and pointerType empty, byte-identical to element.click() on every field except isTrusted. Scoring the shape rather than the trust flag would fail every keyboard-only visitor, which is both a false positive and an accessibility failure. MEASURED, AND SINCE NARROWED.
On SeleniumBase 4.51.3 this row fired readily: a hardcoded tag whitelist (a, button, canvas, div, input, label, li, path, span, svg) took the native path and every other element got element.click(), as did any element located by its text rather than by CSS, and anything on a google domain.
Re-measured on 4.51.5, that whitelist and both extra conditions have been deleted - click() now attempts the native path for everything and falls back only when it throws, so ordinary clicking no longer trips this. The row is kept rather than retired because the synthetic path still exists and is still reachable: click_active_element(), which routes through evaluate("document.activeElement.click()"), measured at isTrusted false, detail 0, clientX 0 on 4.51.5.
A row that only fires on a narrow path is worth keeping when the invariant behind it is exact; it is the version-specific COMMENTARY that has to be dated, not the invariant.
How to resolve it
Drive clicks through the input pipeline - CDP Input.dispatchMouseEvent with a mousePressed/mouseReleased pair at the element's centre - rather than calling element.click(). If you are using a wrapper, check whether it degrades to element.click() for the element type or the selector style you used; several do so silently, and helpers that click 'the active element' are the usual survivor. Nothing to fix for a person clicking normally, with a pointer or a keyboard.
Nearby checks in Automation surface
- 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… - the gesture that started this audit registered as a real user activation
user-activation-vs-interactionThis audit only runs when you press the Run button, and pressing a button is exactly what grants user activation — by pointer, by Enter or… - 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. - 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. - the dropdown change came from the browser, not from a script
interaction-select-change-trustThe same isTrusted argument as the click row, on the surface where the shortcut is most common. - the dropdown fired input before change
interaction-select-input-precedes-changeHTML's "send select update notifications" steps fire input and THEN change when a selection is committed, so the pair is what the algorithm…
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 interaction-click-trust belongs to.