A desktop browser does not expose touch-event feature detection
On a desktop Chromium claim, 'ontouchstart' in window is false, with or without a touchscreen. N/A for mobile claims and non-Chromium engines (severity: warn).
What a detector infers
Whether 'ontouchstart' in window is true is not decided by the hardware. Desktop Chrome turns touch-event feature detection off by default on Windows, macOS and Linux, even on a laptop with a touchscreen: the default is set in slow_web_preference_cache.cc, and only the --touch-events command-line switch or DevTools touch emulation turns it on — current Chrome has no chrome://flags entry for it.
Touchscreens still report themselves, because navigator.maxTouchPoints and the coarse-pointer media queries reflect the real digitiser, so a touch laptop shows touch points while 'ontouchstart' stays false. Measured exactly that way on a Windows PC with a touch digitiser (maxTouchPoints 2) on Chrome and Edge, and false on genuine Linux Chrome. Playwright's hasTouch option, which turns touch emulation on, makes it true.
The rule is deliberately the reverse of the intuitive one: 'touch points, therefore touch events' would flag every real touch laptop, and is not asserted. Developers who launch with --touch-events will trip it. Mobile claims are N/A, as are engines without userAgentData, which follow their own rules.
How to resolve it
Do not turn on touch emulation for a desktop identity (in Playwright, leave hasTouch off). A desktop touchscreen is described by maxTouchPoints and the pointer media queries; touch-event detection stays off unless the browser is launched with --touch-events.
Nearby checks in Screen & display
- An element that went fullscreen gets the screen and the fullscreen display mode
fullscreen-is-real-fullscreenWhen a page calls requestFullscreen() during a click, Chrome normally makes the whole window fullscreen: document.fullscreenElement is set… - A frameless window covering its screen is in fullscreen display mode
frameless-covering-is-fullscreenA desktop browser window has a frame — tab strip, toolbar, borders — so its outer size is larger than its viewport. - devicePixelRatio is the scale layout actually rasterises at
dpr-vs-device-pixelsdevicePixelRatio is meant to be the scale at which layout is rasterised, and several parts of the browser act on the real scale rather than… - Pointer coordinates agree with the window's own position
event-coords-vs-window-geometryA pointer event carries viewport coordinates (clientX/Y) and screen coordinates (screenX/Y), and the browser derives the second from the… - 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… - The screen times devicePixelRatio is a panel a monitor actually has
dpr-screen-vs-panelOn Windows, screen.width and screen.height are reported in scaled pixels — the physical panel divided by the display scale — and at 100%… - 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.
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 desktop-has-no-touch-events belongs to.