The next action must not wait for unfinished motion

What it is

If taps are eaten or deferred until the animation ends while a transition is playing, the next action is tied to the animation clock. The block lives in the input pipeline: hit targets with pointer-events: none, a gesture recogniser waiting on completed, a router waiting for a transition hook to return. In principle motion should yield; this leaf is who, concretely, is holding input when yielding fails.

Why it happens

Interfaces often weld “the pixels are still interpolating” to “the interaction model is still in the old state.” To avoid tapping a half-transparent layer or a button mid-flight, the whole layer stops taking events while isAnimating. The pointer already sits on the new target; the event is queued or dropped. Drops produce a second tap because “nothing happened”; queues produce a double jump when the clip finally ends.

If follow-the-finger scrolling or dragging also waits on the transition, the block turns from one tap into a stuck continuous gesture. The problem is not that duration was set long; it is that input sampling took a lock on animation state. Releasing the lock is not the same as jumping the picture to the end state — that is the mid-state-after-cancel problem — but at least the new intent can enter.

Where it stops holding

• The layer currently being dragged should not also receive a tap-through to what is underneath; that lock is against punch-through, not against the whole app.
• Anti-double-submit after a post is a business lock and belongs on the button’s submitting state, not on a page transition.
• When external UI such as a system permission sheet appears, the app has already lost input; that is not an animation block.

Applying it

• Keep destination hit targets tappable during the animation; a new event should change the route or dismiss the layer immediately, not await the transition.
• Separate “don’t punch through the occluded layer” from “forbid all input.” Block only what is covered.
• Check: at 40% of the transition, tap the primary button or swipe back. If the event only shows in the log after animation end, input was held by the clock.

Related

• Same group: F7.11.2 Interrupted motion still needs a coherent mid-state · F7.11.3 Rapid triggers should coalesce or skip, not queue · F7.11.4 Forced motion feels slow in high-frequency use
• Nearby: F7.10.3 Motion should yield to a faster next action · I1.04 Input delay and finger-following
• Search terms: input during animation · pointer-events · animationend