Keeping a game widget from eating CPU when 40 tabs are open

haibo kan — Fri, 06 Nov 2026 05:47:33 +0000

Collapse, a hidden tab, and switching games all get called "pause". They need three different code paths, and lumping them together is where the state bugs come from.

The widget is a small draggable ball in the corner of every page: click it, pick a game, press Space, click again to fold it away with the round intact. Across forty open tabs, taken literally, that's forty game loops. The CSS half of keeping that ball on arbitrary pages is in an earlier write-up. This is the other half.

The widget is everywhere; the game isn't

The content script mounts one host element, a Shadow DOM root and a drag handler. It does no work when idle. Pick a game and only then does an iframe get created, the bundle load, and the loop start. Switch games or collapse the panel and the iframe is destroyed. No persistent background page holding a loop, no service worker ticking on a timer.

At most one loop per active widget, usually zero. Forty tabs means forty idle elements, not forty requestAnimationFrame loops.

Three kinds of pause

Collapse / Esc — explicit user action. Freeze immediately, keep state. This one has to feel instant.
Tab hidden — the browser already throttles requestAnimationFrame in background tabs. A loop driven by rAF stops advancing on its own; tearing anything down here just adds a state-restore bug.
Switching games — not a pause. Tear down the iframe, start clean. Keeping a hidden game alive "just in case" is exactly how you end up with forty loops.

Store the smallest thing that restores a round

Serializing the whole game object is tempting. Most of it is derived — sprite positions, timers, DOM nodes — and rehydrating it is brittle. What needs to survive:

{
  score: 120,
  level: 3,
  grid: [...],           // board state only
  direction: 'right',
  nextDirection: 'right',
  tick: 1840             // logical ticks elapsed, not wall-clock ms
}

tick instead of Date.now() is the part I'd keep even if everything else changed. Derive your speed curve from wall-clock time and a round that sat paused for twenty minutes comes back at a different difficulty. A logical counter only advances inside the loop.

The other trap is writing on every frame. chrome.storage.local isn't a frame buffer: pause, game over, and a coarse interval, never inside the loop.

One exception, again

Click-through means the widget stops intercepting the mouse entirely. pointer-events: none on the widget surface is the obvious implementation, but the drag handle still needs events. So the handle keeps pointer-events: auto and the rest is disabled as a layer — toggling one global flag leaves you wondering why the ball can't be moved.

What I'd do differently

"Paused" should have been three states from day one. And the save-state shape should have been designed before the game code, not after — deciding what to serialize late is how the game object ends up leaking into storage, versioning a format nobody designed.

If you want to see it running, the extension is InTab Arcade. It's free, with no account and no subscription; a small sponsored banner sits on the game-selection screen.

Injecting a game widget into every page without breaking the host site's CSS

haibo kan — Fri, 06 Nov 2026 03:34:23 +0000

The widget inherits font from whatever page it's on. Shadow DOM doesn't stop that. Neither does it stop color, line-height or text-align.

It's a small draggable ball in the corner of every page. Click it, pick a game, press Space. Click again or hit Esc and it folds away, pausing the game with its state intact. You never open a new tab — so the widget has to coexist with global resets, !important rules, and frameworks with opinions about base styles.

What Shadow DOM stops

A rule targeting .button on the host page won't reach the markup inside my root, and mine won't leak out. That part works as advertised.

Inheritable properties still arrive, though. On a page that sets font-family: "Comic Sans MS" or a cramped base line-height, the widget picks it up. I reset the inheritable set explicitly on :host and put all: initial inside the root before any of my own styles.

Custom properties were the one I didn't expect. They inherit across the boundary by design, so a page with --primary or --radius will quietly restyle your widget if you use either name. Everything is namespaced now — --ita-primary and so on. all: unset on the host side changes nothing; the leak is on the way in.

Then there's the host element itself. It's still a div in someone else's DOM, so div, [class] and broad structural selectors can hit it. Keeping that surface to one element, no classes, styles only on :host, leaves very little to match.

!important from the host doesn't reach in. I test against a handful of real sites with aggressive resets anyway — @layer and constructable stylesheets are worth seeing in practice rather than reasoning about from the spec.

Forty tabs

The quieter failure mode is every open tab paying for a game nobody's playing. Games load on demand into iframes; the iframe is destroyed when you switch away or collapse the panel. State lives in chrome.storage, so teardown doesn't lose the round.

That leaves the content script with a host element, an iframe lifecycle and a drag handler. Nothing else.

One exception to pointer-events

Click-through mode stops the widget stealing a click from the page underneath. pointer-events: none on the shadow host looks like a one-line fix, except the drag handle still needs events — and children can't reliably opt back in with pointer-events: auto in every engine.

The host stays interactive. The inner surface is transparent to pointers, and the handle is the single explicitly interactive child. Otherwise the ball sits there and won't move.

The rest

The extension is completely free — no subscriptions and no account. A small sponsored banner sits on the game-selection screen; its SDK measures impressions and clicks anonymously, with no personal data and no third-party cookies. Widget position, theme and panel size stay local in chrome.storage. It doesn't read browsing history, page content or form data.

The install is heavier than I'd like — the emulator bundle dominates it. Lazy-loading that separately is on the list.

Two questions

Is Shadow DOM still the right call for injected content in 2026, or is there a cleaner isolation pattern I'm missing?

And how do others handle the inherited-property reset without shipping a giant all: initial block?

The extension is InTab Arcade if you want to poke at it.

DEV Community: haibo kan