clicks landed on different points, not the same one repeatedly
Check id pointer-landing-dispersion
What an ordinary browser yields
Several distinct landing points across three or more clicks. N/A below three measurable landings, or for a keyboard or touch visitor (severity: warn).
What a detector infers
Aiming is imprecise. A hand lands somewhere inside a control and the spread shows up within two or three clicks; a driver resolves the element to a box and clicks a computed point, so it lands on the same spot every time. The first version of this row asserted the stronger-sounding claim - that the computed point IS the geometric centre - and measurement refuted it, which is worth recording because it is the more instructive result. On Chrome 150, SeleniumBase 4.51.5 clicking a 36px control landed at dx 0.00, dy -0.72 on all six attempts: not the centre, because CDP's box model hands the driver a CONTENT-box quad while getBoundingClientRect describes the BORDER box, and the control has a border. A centre-seeking row misses that by 0.22px and reports nothing. So the assertion is repetition rather than centring: the offset from centre is bucketed to a tenth of a pixel and only the number of distinct buckets is kept. Six clicks, one bucket, against a hand-driven control arm that produced a different bucket every time. This is both the stronger invariant and independent of which box model the driver happened to read. Two guards: only controls at least 16px in both dimensions count, since on something tiny every landing is near the middle and a hand's spread has nowhere to show; and at least three landings are required, since two agreeing is coincidence.
How to resolve it
Choose a random point inside the element's box rather than a computed one. The value of the offset is irrelevant - what gives it away is that it does not change between clicks.
Nearby checks in Automation surface
- the document was scrolled by something that can scroll it
scroll-input-attributionA document moves for a reason: a wheel notch, a scroll key, a finger, a scrollbar drag - or a script. - the mouse button was held down for a measurable moment
pointer-press-dwell-durationA mouse button is a mechanical switch. Its contacts bounce for several milliseconds before the signal settles, and the hand above it is far… - keys were held down for a measurable moment
key-press-dwell-durationThe keyboard twin of the press-dwell row, and it is deliberately separate because the two fail independently - which SeleniumBase 4.51.5… - movement while a button was down reported the button as down
pointer-buttons-during-dragMouseEvent.buttons is a bitfield of which buttons are currently held, derived by the browser from the physical button state rather than from… - dragging the slider moved it through the values it crossed
slider-drag-value-progressionA range slider is the only common control that has to be DRAGGED to be used as intended, which makes it the only one that produces a stream… - no automation pointer-flash artifact is present
pointer-flash-keyframe-artifactThe only row on this page that works by recognising a specific string, which needs justifying because a name table is exactly what this… - pageXOffset/pageYOffset match their scrollX/scrollY aliases
scroll-alias-coherencewindow.pageXOffset is not a second scroll position, it is a legacy alias of window.scrollX — the specification defines them as the same… - a focused child frame implies its parent document is focused
document-focus-vs-realmdocument.hasFocus() is true when the document OR any of its descendants holds focus, which makes it hierarchical rather than local: a…
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 pointer-landing-dispersion belongs to.