Overflow contacts are dropped silently rather than signaled as errors

What it is

When finger N+1 lands, most systems throw no exception, vibrate nothing, and show no “too many contacts” dialog. The extra contact vanishes from the input stream; existing ids keep reporting as if that finger never existed. The user sees a hand on the glass; the app’s event log is empty. This is a silent drop, not a cancel: the discarded contact has no lifecycle, so there is no cancel to clean up.

Why it happens

Once the slot table is full, controllers typically ignore the new blob, or occasionally evict the oldest or smallest existing blob to make room. Either way, operating systems rarely promote overflow into an error channel apps can subscribe to, because the GUI tradition treats the contact stream as fact rather than a resource allocation that can fail. An app listening only to begin/move/end sees “one begin never arrived.” The user gets no failure signal and cannot convert the dropped finger into a tap—it is not in hit-testing. Worse, some implementations, when an old finger later lifts, adopt the still-resting N+1 finger as a brand-new id, emitting a begin from nowhere, sometimes on the opposite side of the screen.

Studying it

On a device with a known cap, hold N fingers and plant N+1. Align high-speed video with the event log. Independent variables are overflow policy (ignore-new versus evict-old, if vendor docs or observation distinguish them), whether the new finger lands on empty glass or on a button, and the later lift order of the old fingers. Dependent measures are whether a begin appears, whether any error callback fires, whether the control under the dropped finger responds, and whether a late id appears after an old finger lifts. Pair “user says they tapped and nothing happened” with “the log contains no event” to separate silent drops from ordinary misses.

Where it stops holding

Some industrial touch frameworks expose an onPointerRejected style callback; that is the exception, not the consumer-electronics default. When an extra finger is meant as a modifier (three-finger press to open a menu), silent drops make the menu vanish probabilistically and users conclude they have not learned the gesture. Games that map a surplus thumb to fire lose that binding on overflow. A palm occupying a slot looks like “a finger was dropped” but the table was eaten by the heel; separate those silences with area and location.

Applying it

• For anything beyond two fingers, show live id count on a debug HUD; once the device cap is reached, fall back to a visible button or message instead of waiting for a finger that will never arrive.
• Do not treat “finger N+1 landed” as a reliable mode switch; do the same job with a widget or a two-finger gesture.
• Tag “contact visible, no event” as its own defect class in support logs, rather than chasing hit size or latency.

Related

• Same group: C2.18.1 Hardware and the OS cap how many contacts can be tracked at once · C2.18.3 On shared displays the contact cap bounds concurrent participants · C2.18.4 Contact limits vary by device generation and cannot be assumed uniform
• Nearby: C2.16 Touch event models and cancel events · C3.11 Two-finger and multi-finger taps
• Search terms: silent drop · touch overflow · rejected pointer