the document was scrolled by something that can scroll it
Check id scroll-input-attribution
What an ordinary browser yields
At least one scroll following a wheel, scroll key, touch or scrollbar drag. Contextual only, never scored (severity: info).
What a detector infers
A document moves for a reason: a wheel notch, a scroll key, a finger, a scrollbar drag - or a script. The first four leave an event behind; the last leaves nothing. Measured on Chrome 150 against SeleniumBase 4.51.5: scroll_into_view moved the document 2718 pixels in a SINGLE scroll event with zero wheel events and zero key events, and click() does the same because it calls scroll_into_view internally before pressing. The same distance driven through Input.dispatchMouseEvent's mouseWheel type produced 24 scroll events, each following its own wheel - so a driver that scrolls properly is invisible to this row, which is the correct outcome. WHY THIS ROW IS CONTEXTUAL AND NEVER SCORED, which is a deliberate demotion rather than a hedge. The detection side is clean; the false-positive side is not. Script-driven scrolling is ordinary web behaviour - anchor links, a focus() call pulling a control into view, the browser restoring a scroll position on reload, extensions like reading assistants and vim-style navigation - and the audit page itself scrolls three times per run, once when the gate completes, once when the run starts and once when the results land. Those three are excluded by a marker set in scrollIntoViewSafely, but the rest cannot be separated from a driver by anything this page can measure. Scoring it would convict visitors for their extensions and for the page's own behaviour. So it reports what it saw and stays out of the score, with its counters travelling to the corpus; if the data shows that unattributed scrolls are genuinely rare among ordinary visitors, it can be promoted on evidence rather than on one measurement against one wrapper. Scrollbar drags are counted as scroll-capable input specifically so that dragging the bar - which produces no wheel and no key - is never mistaken for a script.
How to resolve it
If you are driving this page, Input.dispatchMouseEvent with a mouseWheel type leaves the same trace a real wheel does, while CDP's DOM.scrollIntoViewIfNeeded leaves none at all. There is nothing to fix as a visitor: a page that scrolls itself is entirely ordinary, which is precisely why this row contributes nothing to the score.
Nearby checks in Automation surface
- 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. - 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 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… - 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…
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 scroll-input-attribution belongs to.