every keypress had a keydown behind it
Every keypress preceded by a keydown. N/A when no keypress arrived, or when composition or paste was used (severity: warn).
What a detector infers
The 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 produces a character. So a keypress arriving with no keydown before it is structurally impossible from a key being pressed, on any engine and any platform.
This is not a check against CDP, which is invisible here when used properly; it is a check against the shortcut of sending only Input.dispatchKeyEvent's "char" type, which injects the character straight into the renderer and skips the keydown the keypress is supposed to be the consequence of. MEASURED, AND NOW FIXED UPSTREAM.
On SeleniumBase 4.51.3 this fired on every character: keypress, beforeinput and input per character, with zero keydown and zero keyup across the whole sequence, against a control arm of proper rawKeyDown/char/keyUp that produced the full five-event sequence. Re-measured on 4.51.5, send_keys now sends the complete triad with key, code and windows_virtual_key_code populated, plus a symbol table so punctuation stops colliding with control keys - it passes this row cleanly.
The invariant is unchanged and still catches anything sending bare char events, which includes 4.51.3 and earlier and several other wrappers; what has changed is that naming this one as an example would now be out of date.
The confounders are all handled by declining rather than judging: IME composition produces keydown with keyCode 229 and no keypress at all, mobile virtual keyboards behave the same way, and paste, autofill and dictation produce input events with no key events - none of those can orphan a keypress because none of them emits one, and the row declines outright whenever a composition or a paste was seen rather than reasoning about an input method it cannot model.
How to resolve it
Send the full triad per character - rawKeyDown with key and code populated, then char, then keyUp - instead of char alone. That is three Input.dispatchKeyEvent calls, and it is what a real keyboard generates and what Playwright's keyboard.type already does.
Nearby checks in Automation surface
- 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. - the clicks this page received were real clicks
interaction-click-trustEvent.isTrusted is set by the engine when it dispatches an event it generated itself, and it cannot be set from script - a constructed… - 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… - 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…
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-keypress-without-keydown belongs to.