pointer coordinates agree with the window's own position
Check id event-coords-vs-window-geometry
What an ordinary browser yields
The viewport position implied by a real pointer event matching the one the window reports, within 3px. N/A for keyboard and touch, which produce no screen coordinates (severity: warn).
What a detector infers
A pointer event carries viewport coordinates (clientX/Y) and screen coordinates (screenX/Y), and the browser derives the second from the first using where the viewport sits on the desktop. It also reports that same position directly, through window.screenX/screenY and the difference between outerWidth/outerHeight and innerWidth/innerHeight. So the frame geometry is one fact described twice: border = (outerWidth - innerWidth) / 2, topChrome = (outerHeight - innerHeight) - border, and then screenX - clientX must equal window.screenX + border, with the vertical axis following the same form. Both sides are the browser's own numbers, which is what makes this unrottable - there is no table of window frame sizes to maintain. MEASURED on Chrome 150: an ordinary window satisfies it exactly (dx 28 against an expected 28); a HEADLESS window satisfies it too, because its window simply sits at negative offscreen coordinates that window.screenX reports honestly - so this is not a headless detector; and 125% Windows display scaling satisfies it to within one pixel of rounding, which is why the tolerance is three rather than zero. What breaks it is a window describing a geometry it does not have. Emulation.setDeviceMetricsOverride, the standard viewport override, was measured producing an expected dx of 108 against an actual 28 and a topChrome of MINUS 56 - not a shape any window has. A script redefining window.screenX/screenY produced an expected 8 against an actual 28, because events are not routed through such an override and keep reporting the truth. This is a SPOOFING row rather than an automation one: it does not catch a driver, it catches a browser whose self-description and whose events disagree. TWO FALSE POSITIVES WERE MEASURED AFTER SHIPPING, and both are now declined or absorbed rather than reported. FIRST, PAGE ZOOM. outerWidth/outerHeight are device-independent pixels that zoom never touches, while innerWidth/innerHeight are CSS pixels that it rescales, so the subtraction above only yields the chrome height at exactly 100%. On a 2x display pressing Ctrl+Minus: at 100% innerHeight 807 and topChrome 86; at 90%, 896 and 63; at 80%, 1009 and 32.5; at 75%, 1076 and 15 - outerHeight fixed at 900 throughout while innerHeight grew past it. A 2x display at 80% zoom reports devicePixelRatio 1.600000023841858, which is exactly the value in the first false-positive report. Fractional DEVICE scaling is NOT the cause and was ruled out separately: real scale factors of 1, 1.25 and 1.6 at 100% zoom gave deltas of 0, 1 and 1.5px. Zoom is now detected as devicePixelRatio divided by outerWidth/innerWidth, which under genuine zoom recovers the display's scale and is never below 1, and under a viewport override came out at 0.75 - so the row declines when zoom explains the impossible frame and still reports when it does not. SECOND, AND LARGER: window.screenY has two implementations. It is documented as the viewport's top edge and is implemented as the outer frame's top edge elsewhere. Measured on two Windows Chrome 150 installs: an automation profile on a single display reported the frame top, giving dy 0; an ordinary profile on a second display reported the viewport top, giving dy -121, exactly minus one topChrome. Nothing in the DOM says which reading a browser has, so asserting one convicts every visitor with the other - and the 88px offset in the original report and the 121px reproduced here are both exactly one chrome height, which is the signature. The vertical delta is therefore measured against the NEARER of the two readings and either counts as agreement; a viewport override still fails both at once, measured at dy -63 against a topChrome of 150, matching neither 0 nor -150. The idea is adapted from brotector, which asserts the cruder pageX === screenX && pageY === screenY - true only for a window at the screen origin with no chrome; reconciling against the window's own reported geometry generalises that to any window position. NOT CLOSED: browser zoom was not tested, and could in principle move the two sides by different amounts. The stored deltas and devicePixelRatio exist so that, if this row starts firing on ordinary visitors, the answer is measurable rather than guessable.
How to resolve it
Size the real window to the viewport being emulated rather than overriding the metrics of a differently-sized window, so outerWidth/outerHeight, window.screenX/screenY and the coordinates on events all describe one window. If window.screenX/screenY are redefined from script, note that events bypass that override entirely.
Nearby checks in Screen & display
- screen.width/height backed by the display (matchMedia)
screen-matchmediaThis check reads window.screen.width/height, then asks the CSS media-query engine the same question via matchMedia("(device-width: Npx) and… - devicePixelRatio matches matchMedia resolution
dpr-matchmediaThe check compares window.devicePixelRatio against the layout engine's own answer, querying matchMedia with a min-resolution/max-resolution… - screen dimensions are a plausible physical size
screen-plausibleA pure sanity range on screen.width and screen.height: both must be at least 200px and no more than 16384px. - the available screen area fits inside the screen
screen-avail-within-boundsThe available screen area is a subset of the screen by definition: availWidth and availHeight describe what is left of width and height… - screen.colorDepth decomposes into the CSS color media feature
color-depth-vs-media-colorscreen.colorDepth and the CSS color media feature describe one display in two different units: total bits per pixel, and bits per colour… - screen has an OS chrome inset (avail < screen on either axis)
taskbar-presentscreen.availWidth/availHeight describe the area left over after the OS reserves space for its own chrome — a Windows taskbar, a macOS dock… - the outer window fits within the screen
window-boundsThe check asserts only the zoom-invariant bound: window.outerWidth/outerHeight must be non-zero and must fit within the screen. - a non-touch desktop has a fine pointer + hover
pointer-hover-desktopThis check applies only when the UA identifies a desktop platform (Windows, Macintosh, Mac OS X, X11, Linux, CrOS, and not Android/Mobile)…
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 Screen & display 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 Screen & display — the family event-coords-vs-window-geometry belongs to.