Mobile (iPhone): user can get locked in browser-level zoom-in state with no clear escape during play #69

New issue

Closed

opened 2026-06-21 23:23:31 +02:00 by bosun · 0 comments

bosun commented

2026-06-21 23:23:31 +02:00

Owner

Symptom (operator playtest 2026-06-21 23:21 iPhone post-round-11)

Operator: "Somehow I managed to lock myself in in a zoom on the controls".

Screenshot shows the play field rendering correctly at the top of the viewport, but the touch controls are clearly cropped on the right edge — LEFT/ROTATE visible but RIGHT is truncated, SOFT DROP visible but HARD DROP is partially cut, CCW visible alone. This is consistent with iOS Safari being in a zoomed-in state that the operator could not exit.

Root cause hypothesis

Despite PR #65 (#64) suppressing rapid-tap-double-tap-zoom via touch-action: manipulation on containers + canvas explicit none, iOS Safari still entered a zoom state. Likely paths:

Pinch-zoom on touch-control area: touch-action: manipulation ALLOWS pinch-zoom (it only suppresses double-tap-zoom + click-delay). If operator's fingers contacted the controls in a pinch-out shape during rapid input, browser-level pinch-zoom would fire. Operator could then escape only via pinch-in or page reload — both non-obvious.
Accessibility zoom (triple-tap): iOS accessibility zoom via three-finger triple-tap is independent of our touch-action suppression. Less likely but possible.
user-scalable=no ignored on modern iOS Safari (per Shipwright's grounding on #64): viewport-level zoom prevention doesn't work, so once zoom fires there's no programmatic way to reset it.

Fix direction (decision tree)

Explicit touch-action: pan-x pan-y on game container (allows touch input but blocks pinch-zoom + double-tap-zoom). More restrictive than manipulation. Most likely to prevent the entry.
touch-action: none on touch-control container (matches canvas treatment) — blocks all browser gestures, only our event handlers fire. Aggressive but unambiguous.
Add an "escape" UI: a small "reset view" button or auto-reset on orientation change. Defense-in-depth for the case where someone DOES get stuck.
Combination: more-restrictive touch-action to prevent entry + escape UI for the case where it still happens.

Note: user-scalable=no cannot be the solution per the prior grounding (ignored on modern iOS Safari).

Workaround for operator while fix is in flight

Operator can escape current stuck state via either:

Full page reload (the refresh button on the Safari URL bar) — resets zoom + page state cleanly
Pinch-in gesture (two fingers, move them together) on any non-canvas area — standard iOS zoom-out

Acceptance criteria

Rapid-tap on controls cannot trigger browser zoom (existing PR #65 fix held)
Pinch-in/out on controls cannot trigger browser zoom
Triple-tap accessibility zoom is out-of-scope (user-controlled accessibility feature)
If operator does get into a zoom state via some path, clear escape mechanism exists (page reload at minimum, or a "reset view" UI button)
No regression on existing touch input (taps, swipes still register normally)

Lane

Shipwright (same CSS family as #64; possibly extends into mobile-session iteration). Could fold into upcoming #59 PR if scope is touched, or standalone S CSS PR.

Effort

Size/S — investigation + scoped CSS refinement + iPhone device-verify.

Anchor

Operator iPhone playtest 2026-06-21 23:21 post-round-11. Refinement family with #60 + #64.

## Symptom (operator playtest 2026-06-21 23:21 iPhone post-round-11) Operator: *"Somehow I managed to lock myself in in a zoom on the controls"*. Screenshot shows the play field rendering correctly at the top of the viewport, but the touch controls are clearly cropped on the right edge — LEFT/ROTATE visible but RIGHT is truncated, SOFT DROP visible but HARD DROP is partially cut, CCW visible alone. This is consistent with iOS Safari being in a zoomed-in state that the operator could not exit. ## Root cause hypothesis Despite PR #65 (#64) suppressing rapid-tap-double-tap-zoom via `touch-action: manipulation` on containers + canvas explicit `none`, iOS Safari still entered a zoom state. Likely paths: 1. **Pinch-zoom on touch-control area**: `touch-action: manipulation` ALLOWS pinch-zoom (it only suppresses double-tap-zoom + click-delay). If operator's fingers contacted the controls in a pinch-out shape during rapid input, browser-level pinch-zoom would fire. Operator could then escape only via pinch-in or page reload — both non-obvious. 2. **Accessibility zoom (triple-tap)**: iOS accessibility zoom via three-finger triple-tap is independent of our touch-action suppression. Less likely but possible. 3. **`user-scalable=no` ignored on modern iOS Safari** (per Shipwright's grounding on #64): viewport-level zoom prevention doesn't work, so once zoom fires there's no programmatic way to reset it. ## Fix direction (decision tree) 1. **Explicit `touch-action: pan-x pan-y` on game container** (allows touch input but blocks pinch-zoom + double-tap-zoom). More restrictive than `manipulation`. Most likely to prevent the entry. 2. **`touch-action: none` on touch-control container** (matches canvas treatment) — blocks all browser gestures, only our event handlers fire. Aggressive but unambiguous. 3. **Add an "escape" UI**: a small "reset view" button or auto-reset on orientation change. Defense-in-depth for the case where someone DOES get stuck. 4. **Combination**: more-restrictive `touch-action` to prevent entry + escape UI for the case where it still happens. Note: `user-scalable=no` cannot be the solution per the prior grounding (ignored on modern iOS Safari). ## Workaround for operator while fix is in flight Operator can escape current stuck state via either: - **Full page reload** (the refresh button on the Safari URL bar) — resets zoom + page state cleanly - **Pinch-in gesture** (two fingers, move them together) on any non-canvas area — standard iOS zoom-out ## Acceptance criteria 1. Rapid-tap on controls cannot trigger browser zoom (existing PR #65 fix held) 2. Pinch-in/out on controls cannot trigger browser zoom 3. Triple-tap accessibility zoom is out-of-scope (user-controlled accessibility feature) 4. If operator does get into a zoom state via some path, clear escape mechanism exists (page reload at minimum, or a "reset view" UI button) 5. No regression on existing touch input (taps, swipes still register normally) ## Lane Shipwright (same CSS family as #64; possibly extends into mobile-session iteration). Could fold into upcoming #59 PR if scope is touched, or standalone S CSS PR. ## Effort Size/S — investigation + scoped CSS refinement + iPhone device-verify. ## Anchor Operator iPhone playtest 2026-06-21 23:21 post-round-11. Refinement family with #60 + #64.