Preventing Focus Loss From Launching a Charged Jump in a Three.js Arcade Game

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

The bug

Solstice Leap is a small Three.js arcade game where the player holds a control to charge a jump and releases it to launch. That makes the distinction between an intentional release and an interrupted input important: a jump can spend daylight, break a streak, or end a run.

I found a bug in that distinction. While charging, switching browser tabs, using Alt + Tab, or otherwise moving focus away from the game caused the character to jump automatically. The game treated the browser's blur event as though the player had deliberately released the jump control.

I recorded the bug in Issue #1 and fixed it in PR #2.

Reproduction

1. Start a run.
2. Hold Leap, the game button, or Space to begin charging.
3. Before releasing the input, switch away from the browser window.
4. Return to the game.

Before the fix, the loss of focus called releaseCharge(). The next landing check then resolved a jump the player did not choose to make, often ending the run with "Missed the platform."

// Previous focus-loss behavior
window.addEventListener("blur", releaseCharge);

blur is not an input-release event. It tells the application that it has lost focus, not that the player has committed to a charged jump.

The fix

I separated the two outcomes in the input lifecycle:

Signal	Correct behavior
Deliberate pointerup or keyup	Release the charge and launch the jump
blur, a hidden document, or pointercancel	Cancel the charge and return to aiming

The new cancellation path clears charge state, restores the player's charged visual scale, removes the button's charging state, and refreshes the UI. Crucially, it does not call the launch code.

function cancelCharge() {
  if (!state.charging || state.mode !== "charging") return;
  state.charging = false;
  state.charge = 0;
  state.mode = "aiming";
  runtime.player.scale.setScalar(1);
  jumpButton.classList.remove("charging");
  updateUI();
}

The browser and pointer cancellation events now use that function instead of releaseCharge():

jumpButton.addEventListener("pointercancel", cancelCharge);
root.addEventListener("pointercancel", cancelCharge);

window.addEventListener("blur", cancelCharge);
document.addEventListener("visibilitychange", () => {
  if (document.visibilityState === "hidden") {
    cancelCharge();
  }
});

Intentional releases are unchanged. pointerup and keyup still call releaseCharge(), so the central charge-and-leap mechanic retains its timing and feel.

Validation

I verified the change in the browser against both sides of the input boundary:

1. Held Leap, triggered the window blur path, and released the pointer. The game returned to aiming mode, the leap count remained 0, and no game-over overlay appeared.
2. Held and deliberately released Leap. The game still launched the player and resolved the landing as normal.
3. Ran node --check game.js to verify the JavaScript syntax.

The merged PR changes only game.js (+18/-3), so the repair stays tightly focused on the faulty input semantics. The current production source is available in the merged pull request and in the live game.

Why this matters

Focus changes are ordinary behavior: players switch windows, operating systems interrupt input, and mobile browsers hide documents. Those events should never silently become gameplay commands.

The fix makes the game more resilient by requiring an explicit release before it launches a charged jump. A player can now leave and return to the game without an accidental action deciding the run for them.

Comments

[Frank]

Interesting approach! Did you consider using pointerlockElement to prevent the focus loss entirely