key events named the key they carried
Check id interaction-key-identity-populated
What an ordinary browser yields
Every keypress naming its character in .key. .code is empty on real keypress events and is deliberately not scored (severity: warn).
What a detector infers
A keypress the engine generates names the character it is delivering in .key. CDP's Input.dispatchKeyEvent with type "char" accepts text without a key, and a driver that supplies only the text leaves .key as the empty string while the character still reaches the field - a keypress that delivered something it cannot name. Measured on Chrome 150: SeleniumBase 4.51.3 UC mode produced keypress events with key "" and keyCode set, against a control arm of well-formed CDP input that produced key "h" for the same character. This is kept as its own row rather than folded into the sequence check above because it reads the CONTENT of the event rather than its ordering, so a driver that fixed one and not the other is still visible. One measured detail decides what is assertable: on a REAL keypress .code is the empty string as well, because code identifies a physical key and keypress describes a character - so only .key can be scored here, and a row that also demanded .code would fail every genuine keypress on the page.
How to resolve it
Populate key, code and the virtual key codes on the keydown and keyUp events you dispatch, and let the char event carry the text. A character arriving in the field from an event that names no key is not a shape the engine produces.
Nearby checks in Automation surface
- 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… - every keypress had a keydown behind it
interaction-keypress-without-keydownThe 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… - 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… - 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 interaction-key-identity-populated belongs to.