a held mouse button reported some pressure
Check id pointer-pressure-on-press
What an ordinary browser yields
Non-zero pressure while a mouse button is held; 0.5 on hardware with no pressure sensor. N/A for touch and pen, whose pressure comes from the digitiser (severity: warn).
What a detector infers
PointerEvent.pressure is not a range to model, it is a constant to check. The Pointer Events spec pins it for hardware with no pressure sensor: 0.5 whenever a button is active, and 0 only when none is. Measured against a PHYSICAL mouse on Chrome 150 - pointerdown with buttons 1 reported pressure exactly 0.5, and the matching pointerup reported 0, precisely as specified. Measured against SeleniumBase 4.51.5 driving the same page through CDP: 0 on the press. Input.dispatchMouseEvent takes an optional `force` parameter and reports zero pressure when it is omitted, which every wrapper measured so far omits. A pointerdown that claims a button is held while reporting no pressure at all is therefore not something a pointing device produces. This row is scored as ZERO-WHILE-HELD rather than NOT-EXACTLY-0.5, and the difference matters: a Force Touch trackpad still reports pointerType "mouse" and hardware could legitimately report 0.42, so demanding the constant would convict honest devices, while demanding merely that a held button produce some pressure cannot, because the spec forbids zero there. A driver can silence this row by passing force: 0.5, and that is the correct outcome rather than a defeat - the row asserts a property of the event, and an event that carries it honestly is not a complaint. PROVENANCE, because it is the point: this is the one row on the page whose baseline came from physical hardware before it was written. The neighbouring key-identity row was reasoned from a CDP control arm and got its justification wrong as a result - the control arm dispatched char events without a code, and the resulting empty value was mistaken for what browsers do. A control arm built from the same protocol as the thing under test is a second sample, not a baseline.
How to resolve it
Pass force: 0.5 to Input.dispatchMouseEvent on the press and 0 on the release, matching what a device with no pressure sensor reports. Nothing to fix for anyone using an actual mouse, trackpad or pen.
Nearby checks in Automation surface
- 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. - arriving over a control and pressing it were separate moments
pointer-arrival-to-press-intervalpointerover fires when the pointer arrives over an element; pointerdown fires when the button goes down. - 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…
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-pressure-on-press belongs to.