Skip to content

Articles

What a Browser Game Should Do When the Tab Goes Hidden

The Page Visibility API tells a game when it is hidden, but not what to do about it. Pausing, muting, and resuming are design choices players should be told about.

Jonah BellOct 19, 20264 min read

Close-up of a hand on a laptop trackpad beside a blurred game board in a browser, with a glowing hourglass suggesting a timer paused while attention drifts away.
A tab change can interrupt a turn, a timer, or only the player’s attention. The game has to define which.

A browser game gets a clear signal when the player leaves, but it does not get a rule for what to do about it. The Page Visibility API tells the page that it is hidden. Nothing in the sources says whether a game should pause, keep running, or end a round. That part is design work, and players feel the result.

Close-up of a hand on a laptop trackpad beside a blurred game board in a browser, with a glowing hourglass suggesting a timer paused while attention drifts away.
A tab change can interrupt a turn, a timer, or only the player’s attention. The game has to define which.

The signal itself is well documented. According to MDN's Page Visibility API overview, the browser fires a visibilitychange event when the user minimizes the window, switches tabs, or has the page covered by another window. MDN lists the API as Baseline Widely available, in browsers since July 2015. The spec text now lives under Page visibility in the HTML Standard's User interaction section.

How to read the visibility signal

You listen for the event on the document, then read document.visibilityState. It returns either visible or hidden. That is the whole vocabulary. The event is not cancelable, so a game cannot veto the change. It can only respond.

The word hidden covers more than a tab switch. MDN's guide to using the API counts a minimized window, a window fully obscured by another application, a switched tab, and an activated OS screen lock. On mobile, switching apps fires the event too, as the MDN event reference notes. A game that assumes the player chose to switch tabs will misread a phone that simply locked in a pocket.

A page that is only partly on screen still counts as visible. So half-covered does not trigger anything.

Visibility is not focus

Focus and visibility are different questions. A tab can be fully visible and still unfocused, for example when the player clicks into another window that sits beside the game. The sources reviewed here do not spell out that difference, so treat the following as a practical reading and test it in your target browsers. Visibility tells you whether the page can be seen. Focus, covered in the HTML Standard's Focus section, concerns which element receives input.

For a game, that means two separate triggers. A hidden page is a strong reason to stop spending the player's resources. An unfocused but visible page is murkier. The player may be watching the board while typing in a chat window. Freezing a timer there could feel wrong, and ignoring keyboard input could feel just as wrong.

One related trap: the hidden attribute on an element, and hiding an iframe with CSS such as display: none, are not the same as document visibility. MDN says hiding an iframe that way does not trigger a visibility change. A settings panel with the hidden attribute tells you nothing about whether the player left.

What to do, by game type

The sources do not prescribe a pause policy, so these are design suggestions, not requirements. MDN's own example is a video that pauses in the background and resumes on return, so the user keeps their place and the audio does not clash with a new foreground tab. Games can borrow that idea.

  • Timed puzzle or trivia round: stop the round clock on hidden and mute audio. Show a resume prompt on return so the countdown does not restart under the player's hand.
  • Turn-based board game: the board can wait. A turn timer is the risk. Pause it, or tell players it keeps running.
  • Idle or strategy game: let the economy continue if that is the point, but stop animation and sound. MDN notes that skipping unnecessary work while hidden saves resources.
  • Live multiplayer round: pausing may stall an opponent. The sources give no guidance here, so decide it as a rule of the match and state it up front.

Take a 60-second word-scramble game. On hidden, it records the time left, stops the clock, and mutes the sound. On visible, it shows a Resume button instead of restarting play. The player never loses seconds to a phone call, and the rule is easy to explain in one line.

Make the return state part of the rule

Pausing is only half the design. When the player comes back, the game should say whether play is stopped, running, or waiting for input. A resume prompt gives a deliberate restart. A short countdown eases the player back into a live round. Automatic resumption can suit a low-stakes game, but it surprises anyone who expected stillness.

Tell players the policy before a costly moment, then keep it consistent. If the clock advances while the game is out of view, say so on the start screen. If progress is saved, say when. If a round cannot safely pause, warn the player before they commit. Patch notes should name any change in these rules in plain terms, such as whether the round clock now stops after a tab switch.

Test it on more than one device. The sources cover the mobile screen-lock case but say little about throttling in background tabs, accessibility, or user expectations, so check those yourself. The verdict is simple. The browser reports that the page is hidden. The game decides what that costs the player, and it should say so before the player finds out the hard way.

Sources

Jonah Bell

Jonah Bell is a house writer for GamesUnlimited who covers strategy games, simulation design, and player economies. He follows systems from tutorial to endgame, testing how patches reshape the choices players make.

More articles

What a Browser Game Should Do When the Tab Goes Hidden | GamesUnlimited