movement while a button was down reported the button as down
Check id pointer-buttons-during-drag
What an ordinary browser yields
Every move made while a button is held reports it as held. N/A when no drag occurred (severity: warn).
What a detector infers
MouseEvent.buttons is a bitfield of which buttons are currently held, derived by the browser from the physical button state rather than from anything the page or the event author supplies. During a drag it is necessarily non-zero: the pointer is moving because a button is down, so a move between a press and its release must report that button as held. A move that reports buttons 0 while a button is down is not unusual, it is contradictory. Measured on Chrome 150 against SeleniumBase 4.51.5, dragging one element onto another: mousedown reported buttons 1, then the intervening mousemove reported buttons 0, then mouseup reported 0. The cause is visible in its source - mouse_drag_async omits the buttons argument on all three Input.dispatchMouseEvent calls, and CDP defaults that field to 0, so the synthesised move announces that nothing is held in the middle of the drag it is performing. The same call also defaults to a single step, so the drag is one jump from origin to destination rather than a path. This row is opportunistic: it says nothing unless a drag actually happened, which costs the ordinary visitor nothing and catches a driver that drags.
How to resolve it
Carry the button mask on the intermediate moves of a drag, not only on the press and the release. CDP's Input.dispatchMouseEvent takes a `buttons` bitfield that defaults to 0, so a mouseMoved sent without it contradicts the press that preceded it.
Nearby checks in Automation surface
- 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… - 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… - clicks landed on different points, not the same one repeatedly
pointer-landing-dispersionAiming is imprecise. A hand lands somewhere inside a control and the spread shows up within two or three clicks; a driver resolves the… - 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…
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-buttons-during-drag belongs to.