Flutter Web in Two Tabs: Both Polling, Both Wrong

Your app works. Then a user opens it in a second tab, and things start going
wrong in ways that never show up in testing.

Both tabs poll the server, so your request volume doubles for one user. Both
hold a WebSocket, so your connection count is wrong and your server thinks you
have twice the traffic you do. Both raise the same desktop notification, so it
appears twice. The user signs out in one tab and the other carries on as though
nothing happened, still showing their data, still refreshing it.

None of this is exotic. Users open second tabs constantly — middle-clicking a
link, restoring a session, or just forgetting the first one is there. It is
routine, and almost no web app handles it.

What the browser gives you, and where it stops

The platform has a primitive for this. BroadcastChannel is a named pipe
between same-origin browsing contexts: post a message on one side, every other
tab on that channel receives it.

That is genuinely useful, and it is where the platform stops. Line up what you
need against what you get:

What you need	What the platform gives you
Messages with a sender	Untyped structured clones, no identity
How many tabs are open	Nothing — you maintain it by heartbeat
Exactly one tab doing the work	Nothing at all

The first gap is an annoyance: every message arrives anonymous, so you invent an
envelope with a sender id in it, and every app invents a slightly different one.

The second is real work. There is no tabs.count. To know how many tabs exist
you broadcast a heartbeat on an interval, track who you have heard from, and
expire the ones that go quiet — and now you own a distributed-systems problem
with timeouts to tune.

The third is the one that actually matters.

Exactly one tab should do the work

Polling, holding a socket, raising a notification, running a background sync —
these should happen once per user, not once per tab. That means the tabs have
to agree on which of them is responsible, and re-agree when that one closes,
without a server and without asking the user.

That is leader election, and it is the part worth a package.

final tabs = CrossTab.open('my-app');

tabs.presence.listen((p) {
  if (p.isLeader) {
    socket.connect();
  } else {
    socket.disconnect();
  }
});

One tab connects. The others do not. Close the connected one and another picks
it up on its own.

The tiebreak is the whole algorithm

The rule is: the oldest tab leads, with the tab id as a tiebreak. The second
half of that sentence is doing more work than it looks.

Suppose you elect purely on age. Two tabs open in the same millisecond — a
session restore opening several at once, which is exactly when this happens —
and now they have equal claim. Each looks at the other, sees a tie, and applies
whatever rule it has. If the rule is "the other one is not older than me, so I
lead," they both lead: two sockets, two pollers, the bug you were trying to fix.
If the rule is "I am not older, so I defer," neither leads and the work stops
entirely.

Adding the id as a second comparison key makes the ordering total. There is
no such thing as a tie, so every tab independently reaches the same answer with
no negotiation round, no lock, and no coordinator. Comparing (age, id) is a
few characters more code than comparing age, and it is the difference between
an algorithm that converges and one that has a race in it.

Leaving politely, and crashing

Two ways a leader stops being a leader, and they need different handling.

A tab that closes says goodbye. beforeunload fires, it broadcasts that it
is leaving, and the others re-elect immediately. This is the common case, and
handling it explicitly is why closing a tab does not produce a gap where nothing
is polling.

A tab that crashes says nothing. No event fires for a killed renderer, an
out-of-memory tab, or a laptop lid closed on a suspended process. So there has
to be a timeout: miss three heartbeats and you are dropped.

You want both. Only the timeout, and every ordinary tab close leaves the app
headless for several seconds. Only the goodbye, and one crash leaves a dead tab
nominally in charge forever.

Presence emits on subscription

A small design decision with outsized consequences:

final p = tabs.current;
p.count;     // how many tabs are open
p.tabs;      // their ids, including this one
p.leader;    // whose turn it is, or null while an election settles
p.isLeader;  // whether that is you

presence emits the current state when you subscribe, not only when
something next changes.

If it only emitted on change, a tab that subscribes during a quiet period sits
there knowing nothing until some other tab opens or closes. Your leader check
never runs, so the socket never connects, and the bug looks like "sometimes it
just does not start" — the worst kind, because it depends on timing you cannot
reproduce on demand.

Note also that leader is nullable. During an election there is genuinely no
answer, and saying null is more honest than nominating a placeholder that
callers then have to distrust.

A tab never hears itself

tabs.send({'cart': items.length});
tabs.messages.listen((m) => print('from ${m.from}: ${m.data}'));

The sender does not receive its own message, because it already knows what it
sent.

That sounds obvious and it removes a real class of bug. If you did receive your
own broadcasts, every handler would need a if (m.from == myId) return; guard,
and the one place you forget is an infinite loop: receive, update state, notify
others, receive.

Off the web, it is always the leader

The package compiles everywhere. On mobile and desktop there is exactly one
instance of your app, so it reports one tab and is always the leader.

That is the correct answer rather than a degraded one, and the distinction
matters. It means the code above runs unchanged on every platform — no
if (kIsWeb) wrapped around your leader logic, no separate code path to keep in
sync, no chance of the mobile build silently skipping the work because nobody
was elected.

A cross-platform package that throws on non-web would push that branch into
every call site. Answering truthfully — one instance, and it leads — makes the
branch unnecessary.

Testing multi-tab behaviour for real

The nice surprise: this is genuinely testable, not mock-only.

Two BroadcastChannel objects with the same name see each other even within
one document. So a test can construct four instances in a single Dart VM under
Chrome and watch them behave like four real tabs, exercising the actual browser
primitive rather than a stand-in for it.

flutter test --platform chrome covers four tabs agreeing on a single leader,
the oldest tab winning, leadership passing when the leader closes, tabs
discovering and losing each other, and a tab not hearing its own messages. The
single-instance path is tested on the VM.

That matters because leader election is exactly the kind of code where a mocked
test proves your mock works. The failure modes live in the timing — two tabs
starting together, a leader vanishing mid-heartbeat — and a fake channel with
synchronous delivery has none of that.

What to put behind the leader check

Once you have this, the question becomes what belongs there. A rough rule:
anything that talks to a server on a timer, or that the user should experience
once rather than once per tab.

Good candidates are polling loops, WebSocket and SSE connections, background
sync, desktop notifications, and scheduled cache refreshes.

Poor candidates are anything the user is looking at. Do not gate rendering,
local state, or reading from cache on leadership — a non-leader tab is still a
tab someone is using, and it should feel identical. The leader does the work;
every tab shows the result.

And separately from leadership, plain broadcast is the right tool for
cross-tab state: sign-out, cart changes, theme switches. Every tab should react
to those, immediately, without a refresh.

The short version

• Second tabs are routine, and an unhandled one doubles your polling, your sockets and your notifications.
• BroadcastChannel is a pipe. It has no identity, no count, and no leader.
• Elect on (age, id), never age alone. The tiebreak is what makes the ordering total, so tabs converge without negotiating.
• Handle both departures: a goodbye on close, and a timeout for a crash.
• Emit presence on subscribe, or a tab that starts during a quiet period never learns where it stands.
• Answer honestly off the web — one instance, always leader — so the same code runs everywhere with no kIsWeb branch.

cross_tab is on pub.dev — MIT, 160/160 pub points, all
six platforms, and the multi-tab behaviour is exercised against real
BroadcastChannel objects rather than mocks.

---

Originally published at devshakib.jumyn.com. I write about Flutter, Dart and the parts of shipping that are genuinely awkward — and publish the packages that came out of them at pub.dev/publishers/jumyn.com.