Multi Touch Test

Introduction

The DeviceHub Multi Touch Test is a free online simultaneous-contact visualizer that shows multiple touch points and peak finger count in the browser, without OEM multi-touch lab benches, without claiming that marketing “ten-point touch” equals what Safari or Chrome will deliver to a webpage, and without installing vendor gesture recorders. Game developers validating pinch and rotate affordances, support teams reproducing “second finger ignored” bugs, educators demonstrating TouchEvent.touches length, QA checking refurbished tablets after glass replacement, musicians testing multi-finger web instruments, and classroom facilitators contrasting mouse-only desktops with phones all place several fingers on one HTTPS pad and watch identifiers update live. Many mobile sensor and advanced touch diagnostics are mobile-oriented; desktop browsers often report unsupported, and that outcome is still useful capability evidence rather than a DeviceHub defect. This page does not replace Touchscreen Test for simple tap smoke, does not replace Trackpad Test when OS two-finger scroll and laptop gesture cancellation dominate, and does not measure stylus pressure or contact area in laboratory microns. Pair with Touchscreen Test for single-contact baselines and corner dead-zone hunts. Pair with Trackpad Test on notebooks where Precision Touchpad gestures steal events from the page. Pair with Device Information for maxTouchPoints hub context beside viewport and DPR. Pair with Orientation Test when multi-touch fails only after rotate-to-landscape. Pair with Accelerometer Test or Gyroscope Test when motion and multi-touch interact in AR-like web demos that listen to both streams. Permissions stay none, no camera, microphone, geolocation, or clipboard prompts merely to count fingers. Schools use Multi Touch Test to show that browser-exposed peaks can be lower than retail box claims, teaching honest web-platform limits rather than accusing DeviceHub of undercounting. Capture inside the WebView that hosts your product; embedded browsers frequently clamp contacts differently from standalone Chrome or Safari on the same handset. Wet screens, glove modes, and thick tempered glass reduce reliable simultaneous points, retest bare-finger dry glass before RMA paperwork. DeviceHub never uploads finger trajectories for advertising when you view the page; results stay on-device diagnostics you choose to screenshot. Peak counts are session observations, not warranty certificates for OEM digitizer channels, and tickets should label them as browser-visible contacts with engine name attached.

What this tool does

Multi Touch Test listens for multi-contact touch events, draws each active point, tracks identifiers across moves, and records peak simultaneous fingers during the session so you can compare advertisement versus reality in-browser. It may surface navigator.maxTouchPoints as a capacity hint beside observed peaks, clarifying that a hint of ten does not guarantee the page will receive ten events under OS gesture recognition. It does not enable Windows Precision Touchpad certification modes, does not rewrite Android touchscreen firmware, and does not claim laboratory-grade ellipse major/minor axis measurements. Guidance explains OS gesture steal where the browser may lose points mid-pinch, iOS versus Android identifier stability differences, why desktop mouse emulation never proves phone multi-touch, and how palm rejection removes intentional edge fingers. DeviceHub typed permissions remain none (PermissionKind has no geolocation or motion member); OS or browser prompts may still appear for geolocation or motion, editorial copy explains those prompts without inventing union values. Users are directed to Touchscreen Test when only one finger needs smoke validation and to Trackpad Test when the hardware is a click-pad. Refresh after rotating so coordinate spaces match the orientation under test. The UI never invents ghost fingers to flatter marketing specs, if the browser delivers one contact, you see one. Closing the tab clears the session peak unless you screenshot first. Notes remind support staff that peak three on a “ten-point” panel can still be a browser or driver clamp, not necessarily a dead digitizer channel, and that high CPU background tabs can drop moves and undercount peaks without any glass damage.

When to use it

Use Multi Touch Test when pinch-zoom fails in a PWA, when users report only the first finger draws in a sketching web app, when accepting used tablets after glass replacement, when teaching touches.length in web courses, when comparing Chrome versus Safari contact caps on the same handset, and when filing framework bugs against touch handlers so you attach peak-count evidence instead of vague “broken multitouch” text. Prefer Touchscreen Test for single-tap dead-zone hunts and corner registration smoke. Prefer Trackpad Test for laptop two-finger scroll and three-finger OS gestures that never appear the same way on phones. Prefer Device Information when maxTouchPoints belongs beside viewport in one note for responsive tickets. Prefer motion sensor tools when the bug is device tilt during multi-touch, not contact count. Avoid treating observed peak as a legal warranty of OEM ten-point claims. Avoid testing with screen-recording overlays that inject synthetic touches and create false passes. Retest after enabling game mode, after glove settings, after installing new screen protectors, and after switching between Samsung Internet and Chrome. Use in classrooms to contrast mouse-only desktops, often unsupported multi-touch, with phones that show several points. Use before blaming CSS touch-action alone when the digitizer never delivers a second identifier to JavaScript.

How it works

TouchEvent exposes touches, targetTouches, and changedTouches lists; browsers assign identifiers per contact while fingers remain down. DeviceHub renders those lists and computes a session peak from what the engine actually delivers. navigator.maxTouchPoints remains a hint, not a guarantee under OS gesture recognition, accessibility filters, or enterprise touch policies. Typed permissions stay none, multi-touch reading needs no Permissions API camera or microphone category. Secure context is standard for DeviceHub hosting. Desktop engines without touch hardware cannot magically create multi-touch; unsupported or single-point outcomes are expected and useful in capability matrices. iOS may require careful handling of default gesture behaviors via touch-action CSS, DeviceHub’s pad is designed for diagnostics, not to defeat every Safari callout or system pinch. Chromium on Android can drop contacts under extreme main-thread blocking; close heavy tabs before concluding hardware failure. Palm rejection removes intentional edge fingers, retry inset from bezels. In-app WebViews and privacy browsers may clamp differently from full Chrome. No DeviceHub server needs your touch stream to render labels, processing stays local. Fingerprinting via peak multi-touch behavior is possible but uncommon; still minimize public video of unique gesture patterns on shared devices. Compared with Generic Sensor APIs elsewhere in this category, multi-touch does not need Chromium-only Accelerometer Permissions-Policy battles, but Accelerometer, Gyroscope, and Magnetometer pages do, so keep honesty siloed per tool. On iOS, DeviceOrientation and DeviceMotion access typically require a user gesture plus an explicit system permission prompt before samples flow. That iOS rule matters more for Orientation and motion tools than for basic multi-touch counting, yet the suite intro should stay consistent when students jump between pages.

Step-by-step instructions

1. Open Multi Touch Test over HTTPS on the touch device and browser (or WebView) where multi-finger gestures fail, avoid DevTools emulation unless you intentionally want fake contacts.
2. Place two fingers, confirm two points, then add more contacts gradually while watching peak count climb.
3. Try a slow pinch and a two-finger rotate if your bug involves gestures; note if the OS cancels browser events mid-stroke.
4. Compare observed peak with maxTouchPoints on this page or Device Information, labeling gaps as browser/OS limits when appropriate.
5. Run Touchscreen Test for single-finger corner smoke and Trackpad Test if the device is a laptop trackpad rather than a phone panel.
6. Screenshot peak count with browser name; do not claim OEM laboratory certification from a webpage.

Common problems

Desktop unsupported or single-point results mistaken for DeviceHub bugs, often expected without a touchscreen. OS pinch gestures cancel page events so fingers appear to disappear mid-stroke. Wet glass merges contacts into one ellipse the browser reports poorly. Gloves and thick protectors reduce peaks below marketing claims. Assuming maxTouchPoints equals guaranteed peak overreaches browser hints. WebViews clamp below standalone Chrome on the same phone. Remote agents testing on PCs cannot validate user phones. High CPU jank drops moves and undercounts peaks. Confusing Trackpad Test gesture cancellation with phone digitizer failure misroutes tickets. Palm rejection eating intentional edge fingers. iOS callouts interrupting long-press multi-touch drills. Marketing ten-point claims versus browser peak three creating false RMA expectations, document platform honesty. Screen recording software injecting synthetic touches creates false confidence. Ignoring orientation: landscape hit targets differ after rotate, pair with Orientation Test when only landscape multi-touch fails.

Privacy explanation

Multi-touch trajectories display locally and are not uploaded by DeviceHub for advertising when you view the page. Permissions stay none, no geolocation prompt is required to count fingers, unlike GPS Test which explains its own browser location dialog while typed metadata remains none. Close the tab to stop listening. Avoid recording unlock-like multi-finger patterns on shared classroom devices. Share peak integers only when tickets need them; qualitative “two-finger works” often suffices for support. Combined with device geometry from Device Information, detailed touch videos can aid fingerprinting, minimize public posts. No Chromium Magnetometer Permissions-Policy battles apply to basic touch counting, unlike Magnetometer Test in this suite, keep privacy notes tool-specific when students compare pages.