| Component name | touch_support |
|---|---|
| In the visitorId | yes |
| structuredId group | device (screen, memory, CPU) |
| Hashing | plain value; a digest only when longer than 128 characters or not printable ASCII |
| Excluded under | no browser class |
| Inner timeout | 1000 ms |
| Added in | signalsVersion 1 |
Touch screens report how many fingers they can track at once, and browsers on touch devices offer touch events to pages. WhiskerJS writes down three simple facts about this. A desktop usually says no touch at all, a phone says five or more touch points and touch events, and touch laptops are somewhere in between.
What it reads
navigator.maxTouchPoints(or the oldmsMaxTouchPoints), 0 when missing;- whether
document.createEvent('TouchEvent')succeeds (1) or throws (0); - whether
ontouchstartexists on the window (1 or 0).
The value is points=<n>,event=<0|1>,start=<0|1>.
How the technique works
Each part is read in its own guard, so a missing property or a throwing call only sets that part to 0. Together they describe the input hardware and how the browser exposes it, which separates more cases than any part alone: desktop browsers, touch laptops, tablets that present a desktop user agent, and phones.
Why it helps
It splits device classes cheaply and is a useful consistency check for your server: a phone user agent with points=0,event=0,start=0, or a desktop platform with ten touch points, is unusual. It is in the device group.
Stability
Stable for a given device and browser. It can change when a touch screen or pen tablet is attached, when a browser’s device emulation is switched on in developer tools, or with a browser update that changes which touch APIs are exposed.
Browser support and what blocks it
ok in all browsers; not in the exclusion table. Typical values: points=0,event=0,start=0 on desktops, points=5,event=1,start=1 on phones. See Chrome on Android, Safari and every iOS browser and Samsung Internet for touch devices.
Privacy
Three coarse facts about touch input. No permission, no prompt, no request; no touch event is listened to or dispatched.
How WhiskerJS handles noise and failures
| Status | ruleId | When |
|---|---|---|
ok |
none | always, in practice |
blocked |
security_error, threw |
only if something outside the guards throws (not expected) |
excluded |
caller_excluded |
your exclude list |
timed_out |
timeout, aborted |
1000 ms inner timeout, budget, abort |
Example value
From the headless test browsers in a container: points=0,event=0,start=0 (Chromium and Firefox) and points=0,event=1,start=0 (WebKit).
"touch_support": { "status": "ok", "value": "points=5,event=1,start=1", "hashed": false }Questions and answers
Why does a desktop sometimes show event=1?
Some browsers let pages create a TouchEvent even without a touch screen; the headless WebKit test browser used for these pages did. That is why WhiskerJS reports three separate parts instead of one yes or no.
Can touch_support fail?
Practically not. Each part has a safe default of 0, so the component is almost always ok. It can only be excluded by you or time out.