MC board mobile: cannot touch-scroll down (recurring regression) — add regression guard
## Bug: MC board cannot be scrolled down on mobile (RECURRING regression) **Reported:** Elmar, 2026-06-11 — "again has this issue where on mobile you can't scroll down." Has re...
StateWaitingNext ActionWaiting: your real android touch scroll confirmationOwnerLuciRuntimeIdleAge2d ago
Last runtime ended unexpectedly.·profile claude_opus_1m_medium
Description
MC-4950
## Bug: MC board cannot be scrolled down on mobile (RECURRING regression)
**Reported:** Elmar, 2026-06-11 — "again has this issue where on mobile you can't scroll down." Has regressed multiple times (git: "Fix mobile board vertical scroll", "fix board v2 mobile segment scrolling", "restore mobile scroll", "Board v2 mobile design QA").
### Findings so far (Luci, headless @390px iPhone UA)
- The page DOES scroll programmatically: document scrollHeight 1737 vs viewport 844; `window.scrollTo(0,99999)` moved to y=893. `html`/`body` overflow-y: visible; body grows with content (`padding-bottom: calc(--bottom-nav-height …)`).
- board_v2.html swipe handlers (MC-4775) are `{passive:true}`, touchstart/touchend only, NO touchmove/preventDefault → they do NOT block scroll.
- No board scroll-lock found; the `height: calc(100dvh - …)` rules in style.css:160-189 belong to `.app-dock-*` (App catalogue), not the board.
- So programmatic scroll works headless — the failure is **touch-specific** (real-device finger scroll), which headless `scrollTo` can't reproduce. Likely a non-passive `touchmove` preventDefault, `touch-action:none`, or a fixed overlay capturing touches — possibly in base.html / global JS / the bottom-nav dock, not board_v2.html itself.
### Required
1. Reproduce real TOUCH scroll at mobile width (CDP Input.dispatchTouchEvent / real device), pinpoint the element/handler that eats the vertical drag.
2. Fix.
3. **Add a regression guard** — this keeps coming back. The Canary board battery is mandated for board changes but is NOT catching touch-scroll. Add a mobile touch-scroll assertion to `tests/canary/board_battery.js` (drive a touch-drag, assert scrollY changed).
4. Gate: restart luci-dashboard + Canary board battery green + Tessa mobile touch journey.
### Constraints
- Tier 2 UI. Files likely: templates/base.html, static/style.css, static/app_dock.js or board JS. board_v2.html itself looks clean.
- MC CLAUDE.md: board changes MUST pass `python3 tests/canary/run_board_battery.py` before DONE.
Activity
waiting
INTERACTIVE
Luci is working...
Details —
Waiting
· High
· Luci
▼
SState
Waiting
Waiting: your real android touch scroll confirmation
PPeople
TTiming / Details▼
api (human)
Mission Control
2d ago
2d ago
Advanced / Operator evidence
RRouting owner
ROperator console
Last runtime ended unexpectedly.waiting_on_elmar_real_android_touch_scroll_confirmationprofile claude_opus_1m_mediumMC is visibility-only. Hermes Luci launches and gates work outside MC, then mirrors evidence/status here.
WWorkflow
Start Dev Review + QA ▾
Select phases to include:
Agents
Review Gates
Decision
WAT routing: choose an agent, review gate, or decision. Buttons use the live runtime when one is attached.
CANDIDATE FIX deployed (Luci, 2026-06-11) — UNVERIFIED on real Android, needs Elmar confirm.
Tessa diagnosis (full: tests/tessa-board-mobile-scroll.md): rigorous method (real CDP touch-drag, iPhone + Pixel UA, multiple configs) but **could NOT reproduce** — headless scrolls 0→822px in every config. The bug is real-Android-compositor-specific; no headless/emulated tool here reproduces it.
Correcting Tessa's PRIMARY root cause: she blamed `-webkit-overflow-scrolling: touch` on `.v2-mobile-switcher` creating a momentum-scroll layer that traps touches. That's technically wrong — Chrome ignores `-webkit-overflow-scrolling` entirely (iOS-only), and it's inert on a `overflow-x: visible` / flex-wrap element. Removing it alone would do nothing on Android.
Applied the correct-mechanism fix instead (board_v2_panel.html `.v2-mobile-switcher` @media max-width:700px):
- dropped the no-op `-webkit-overflow-scrolling: touch`
- added `touch-action: pan-y` — explicitly tells the compositor vertical panning passes THROUGH the tabs bar, so a drag starting over the segment tabs can't trap page scroll.
Deployed: workers cycled, live /board serves `touch-action: pan-y`.
Still UNVERIFIED on device (tooling can't reproduce). If it's still broken, the stronger remaining suspect is `overflow-x: clip` on `.v2-board-shell`/`.v2-panel-wrap`/`.v2-kanban` (board_v2.html:16-17,148-149) — a known Android-Chrome `overflow:clip` compositor quirk — which needs real-device iteration.
Diagnostic that distinguishes the two (one question to Elmar): does scroll fail EVERYWHERE, or only when the finger starts over the top tabs (In/Act/Needs)? Top-only → switcher fix (this) is right. Everywhere → it's the overflow-x:clip shell.
Regression guard: still OPEN. The mandated Canary board battery runs headless and CANNOT catch this device-compositor class. A real-device check is the only guard; note this for the fix-author.
luci-board-manager2d ago
[visibility-only controller] Routed this Luci-owned technical mobile-scroll regression to internal Kanban card t_3d178879 (assignee codexbuilder) in isolated worktree `/home/lucienne/workspace/_mc_internal_worktrees/MC-4950-touch-scroll-regression`. Dispatch verified running pid 1628515 with `/proc/1628515/cwd` equal to that isolated worktree after a stability recheck. MC remains visibility-only: no MC pickup/runtime endpoints were used. Acceptance remains: touch-scroll repro/fix, board_battery touch regression guard, canary battery, and controller live/deploy gate.
luci-board-manager2d ago
[visibility-only] Controller consumed the internal Kanban technical handoff for the recurring mobile touch-scroll regression. The remaining blocker is not more MC runtime work: the candidate fix/guard is recorded, but the issue was not reproducible in headless/CDP and needs Elmar to try the live Board on the real Android device that showed the regression. CTA: please test mobile Board vertical scrolling on that device and reply whether it now scrolls. MC remains ledger-only; no MC pickup/runtime endpoints were used.