Skip to content

fix(paddle-card): Release nav buttons during play so users can exit#75

Open
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/paddle-card-release-nav-buttons
Open

fix(paddle-card): Release nav buttons during play so users can exit#75
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/paddle-card-release-nav-buttons

Conversation

@posthog

@posthog posthog Bot commented Jun 16, 2026

Copy link
Copy Markdown

Summary

A user playing DeskHog's built-in Paddle game reported being stuck — once the game started, the up/down buttons no longer scrolled to other cards, so there was no way to exit back to the rest of the UI.

Root cause

PaddleCard::handleButtonPress (src/ui/PaddleCard.cpp) returned true for BUTTON_CENTER, BUTTON_UP, and BUTTON_DOWN whenever the game was in StartScreen, Playing, Paused, or ServeDelay. Returning true tells CardNavigationStack the event was handled, so it never gets a chance to use Up/Down to scroll to the next/previous card (CardNavigationStack::handleButtonPress only navigates on BUTTON_UP/BUTTON_DOWN when the active card returns false).

The adjacent GameOver/StartScreen branch already released Up/Down for navigation, but that release was never extended to the active-play states. FlappyHogCard does not have this issue — it returns false and lets navigation through.

Introduced in c88bd01 (Paddle IP compliance pass).

Fix

Mirror the FlappyHog pattern:

  • Center is always owned by PaddleCard (start / pause / resume / restart). Navigation never uses center, so consuming it stays safe.
  • Up/Down are consumed only while GameState::Playing, where they drive the paddle. In StartScreen, Paused, ServeDelay, and GameOver they now fall through to CardNavigationStack so the user can always scroll away.

To leave mid-game the user presses Center to pause, then Up/Down to navigate out — the intended flow.

Notes

The same signal report also surfaced a "want more game variety" complaint. That's deliberate product scope (the team adds games via the /examples flow), not a code defect, so it's intentionally left out of this PR.

Addresses PostHog inbox report 019e0482.

🤖 Generated with Claude Code

…n exit

PaddleCard::handleButtonPress consumed BUTTON_UP and BUTTON_DOWN whenever
the game was in StartScreen, Playing, Paused, or ServeDelay state, swallowing
the events before CardNavigationStack could use them to scroll to another card.
This trapped the user inside the game once it started — they could not navigate
away, which a user reported as being "stuck".

Mirror the FlappyHogCard pattern: only consume Up/Down while the game is
actively being played (GameState::Playing, where they drive the paddle). In
every other state let Up/Down fall through to CardNavigationStack so the user
can always exit. Center remains owned by PaddleCard for start/pause/resume/
restart; navigation never uses center, so consuming it is safe.

Introduced in c88bd01 (Paddle IP compliance pass).

Generated-By: PostHog Code
Task-Id: bb75f66f-cae8-440b-8de6-61a727af6754
@posthog posthog Bot requested a review from daniloc June 16, 2026 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants