the text in the field arrived through events
Check id interaction-value-without-events
What an ordinary browser yields
Input events accompanying the text in the field. N/A when the field is empty, or when a paste or composition was seen (severity: warn).
What a detector infers
Text cannot appear in a field without the engine having put it there, and every route the engine offers announces itself with an input event - typing fires one per character, paste fires one, autofill fires one, dictation fires one. Assigning .value from script is the single way to change what a field holds while telling nothing, which is what a driver's set_value helper does. Measured on Chrome 150 against SeleniumBase 4.51.5 - the release that had just fixed send_keys and removed the click whitelist - typing the same five characters into three identical fields by three routes: send_keys produced 5 input, 1 change and 5 keydown; set_value produced 0 input, 0 change, 0 keydown and 0 paste; a genuine paste produced 1 input and 1 paste. Five characters materialising with no event of any kind, while the confounder that most resembles it still announces itself, is what makes this scoreable rather than a guess. The row declines whenever something legitimately fills a field quietly - a paste or an IME composition, both counted by the watcher - or when the field is empty and there is nothing to explain. One residual false positive is real and is stated in the row's own detail rather than pretended away: a password manager that assigns .value directly instead of dispatching input produces exactly this shape. That is why it is warn and not critical.
How to resolve it
Set field values through the input pipeline with real key events rather than assigning .value. If you must assign it, dispatch an input event afterwards - and note that assigning .value directly is also what breaks React and similar frameworks, which read the event rather than the property, so this is a correctness bug before it is a detection one.
Nearby checks in Automation surface
- 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… - 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 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. - 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.
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-value-without-events belongs to.