hansdezwartandClaude Opus 5
632f1ef47d
Android's swipe-up-from-the-bottom is how you leave an app, and the bottom panel owns that edge — .app is 1fr auto 1fr with the bar in the middle, so both panels run to the screen edges. Acting on pointerdown meant starting a swipe home was a finger landing on the clock, and the turn changed before the gesture had even been recognised. The status bar over the top panel has the same problem. Android won't let an app opt out either; setSystemGestureExclusionRects is ignored for the home gesture. So a tap is now a press and a lift in the same place, within 12px. A swipe travels further; a gesture the system claims arrives as pointercancel and never becomes a lift. The clock is still stamped at the press. tap() takes the pointerdown timestamp, which meant dropping elapsed() for now - st.turnAt — elapsed() always measures to the current instant, the one thing that can't be backdated. With the delay forced to 0, holding a finger down 600ms longer charges the outgoing player 1033ms against 1037ms for an instant lift: the same thinking time, not the extra 600. The fullscreen request moved to the lift too, so a swipe can't force it. touch-action:none on .panel means a slow drag ends in a lift we reject rather than a cancel the browser issues on its own account; it changes no pixels. Falls out of it: a hand dragged across a live panel no longer flips the turn, which the README only promised of the waiting player's hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>