arriving over a control and pressing it were separate moments
Check id pointer-arrival-to-press-interval
What an ordinary browser yields
A non-zero interval between arriving over a control and pressing it. N/A when no arrival/press pair was observable, and for touch and pen, where simultaneity is legitimate (severity: warn).
What a detector infers
pointerover fires when the pointer arrives over an element; pointerdown fires when the button goes down. For a physical mouse those are two separate hardware reports with real time between them - the pointer enters, and some time later a finger presses. Measured on Chrome 150 against SeleniumBase 4.51.5: zero milliseconds, arrival and press reported at the same instant, against 225ms for a control arm of CDP input driven like a hand. Kept separate from the movement row because the two fail independently: a driver that adds an approach path can still press the moment it lands, and a driver that lands plausibly can still send the whole burst in one tick. Scored at EXACTLY zero rather than against a reaction-time threshold, and that is deliberate - a threshold would be a model of how fast humans are, which is the kind of claim this audit refuses to make, and a genuine fast flick can be very quick indeed. Zero is not fast, it is simultaneous, and simultaneity is a property of how the events were generated rather than of how quickly anyone moved. The row declines rather than guessing whenever the pointer was already over the control when it pressed, which is the ordinary case for someone who hovers before clicking and leaves no arrival to time.
How to resolve it
Separate the move from the press: land the pointer, then dispatch mousePressed on a later tick. Sending the approach and the press in one burst collapses them into a single timestamp, which no physical input produces.
Nearby checks in Automation surface
- 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… - the text in the field arrived through events
interaction-value-without-eventsText cannot appear in a field without the engine having put it there, and every route the engine offers announces itself with an input event… - the pointer moved before it clicked
pointer-movement-precedes-clickA mouse reaches a target by crossing the document, and every position it crosses is an event. - a held mouse button reported some pressure
pointer-pressure-on-pressPointerEvent.pressure is not a range to model, it is a constant to check. - 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…
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-arrival-to-press-interval belongs to.