Reconnect the terminal view when somebody comes back to it

Going back to a terminal left alone for a while found it stuck on
"Reconnecting the terminal view…", and stuck is the right word: the banner
stayed and nothing behind it was reconnecting.

The page's whole recovery story was a setTimeout chain, and a chain is exactly
what a WebView is entitled to stop running. Chromium throttles timers in a page
nobody is looking at — down to once a minute once it has been hidden five
minutes — and a renderer that is frozen, or reclaimed and not yet reloaded,
runs none of them. So the socket drops while nobody is watching, the banner
goes up, the retry is scheduled, and the retry is then the one thing not
running.

Three defects, each of which leaves that banner up for the rest of the page's
life.

◆ NOTHING LISTENED FOR THE PAGE COMING BACK. The only thing that could clear
the banner was a timer that may never fire. terminal.js now reconnects on
visibilitychange, focus and online — the events that mean somebody is looking
again, and the ones that cannot be throttled — cancelling the pending timer and
resetting the backoff. Over a healthy socket all three do nothing, which is
what makes them safe to fire as often as clicking a window does.

◆ A HANDSHAKE THAT NEVER FINISHED WAS INVISIBLE. Every retry was scheduled by a
close or an error, so an attempt parked in CONNECTING — which is what a
suspended renderer leaves behind — scheduled nothing at all, ever. There is now
a five-second watchdog on the handshake.

◆ STALE SOCKETS SCHEDULED RETRIES, AND THAT ONE IS A LOOP RATHER THAN A STALL.
connect() never detached the old socket's handlers, and the host aborts the
displaced socket on takeover — TerminalDataPlane.UpgradeAsync, doing exactly
what it should. That close read as a fresh failure and scheduled a retry
against the socket that had just succeeded, whose own close scheduled the next:
no fixed point, reconnecting every second forever with the banner up for most
of it. Every handler now asks whether it is still the page's own attempt, and
connect() closes what it abandons.

◆ WHICH OF THE PLATFORM BEHAVIOURS ACTUALLY BIT IS NOT ESTABLISHED, and the fix
does not depend on knowing. Throttled timers, a frozen renderer and a reclaimed
one all end at the same dead timer; guessing between them would have produced a
narrower fix for one of the three.

THE TEST RUNS terminal.js ITSELF, in a fake browser, inside dotnet test.
RendererPage loads the file the shell project ships — not a transcription of its
logic into C#, which would be a copy that stays correct while the page rots —
into a Jint engine, one per test, over a harness that fakes a WebSocket and a
clock and nothing else. Jint rather than a node script because CI would run the
node one and nobody's inner loop would; the cost is that Jint is not Chromium,
so this proves the page's logic and nothing about how a WebView behaves. That
line is drawn in RendererPage's remark and picked up by two new manual checks,
1.10 for the desktop and 11.12a for the phone, which own the platform half.

Four of the nine tests fail against the page as it stood — the stale close, the
parked handshake, and the two wake-ups. Two more assert that a wake-up over a
healthy socket does nothing, and pass against either version on purpose: they
are what stops the cure being worse.

Left alone deliberately: a socket that is open and dead shows no banner at all,
because readyState still reads OPEN. That looks like a terminal that swallows
what is typed, needs a liveness probe rather than a faster retry, and is written
down at the end of 11.12a rather than quietly bundled in here.

src/DodoSSH.Client.Shell/WebAssets/terminal.js

@@ -16,7 +16,8 @@
      happened to straddle a frame boundary, which shows up as occasional mojibake in exactly the
      conditions that are hardest to reproduce.
 
-  3. The socket reconnects itself, forever, with backoff. This page's WebView is routinely killed
+  3. The socket reconnects itself, forever, with backoff — and on being looked at again, which is not
+     the same thing and is the half a timer cannot cover. This page's WebView is routinely killed
      and reloaded by Android under memory pressure or simply for being backgrounded, so "the
      socket closed" is an ordinary event here, not the end of the terminal's life — see connect().
      A reloaded page starts with an empty session map, so createSession is idempotent (a session
@@ -52,6 +53,22 @@ const SCROLLBACK_LINES = 5000;
 const RECONNECT_INITIAL_DELAY_MS = 1000;
 const RECONNECT_MAX_DELAY_MS = 5000;
 
+/*
+  How long a socket is given to finish its handshake before it is treated as a failure.
+
+  A socket that cannot connect normally says so and says it quickly — 'error' then 'close', within a
+  millisecond or two of a loopback refusal. The case this covers is the one that says nothing: an attempt
+  parked in CONNECTING with no event ever coming, which is what a WebSocket opened by a renderer that is
+  then suspended, or one whose handshake the host never answers, leaves this page holding.
+
+  Without the watchdog that state is terminal, and quietly so. Every retry in this file is scheduled by a
+  close or an error, so an attempt that produces neither schedules nothing: the banner says the view is
+  reconnecting for the rest of the page's life while nothing whatever is reconnecting. Five seconds is
+  generous against a handshake that ordinarily takes about a millisecond, and short against somebody
+  waiting on their terminal to come back.
+*/
+const HANDSHAKE_TIMEOUT_MS = 5000;
+
 /*
   Styled like the SESSION_CLOSED banner (matching \x1b[38;5;244, the same dim grey), but written by
   createSession's caller rather than by createSession itself: only a *replay* landing on a pane that
@@ -583,8 +600,47 @@ function handleFrame(buffer) {
   }
 }
 
+/*
+  ── THE SOCKET COMES BACK BY ITSELF, INCLUDING FOR A PAGE NOBODY HAS LOOKED AT IN AN HOUR ────────────
+
+  Retrying on a timer is the easy half and was the whole of this. The three rules below are what make the
+  retry actually reach a page that has been sitting collapsed — each of them a way this page was found
+  showing "Reconnecting the terminal view…" over a socket that nothing was reconnecting.
+
+  1. ONLY THE CURRENT ATTEMPT'S EVENTS COUNT. connect() abandons whatever socket was attached before it,
+     and an abandoned socket still reports its end: the host aborts it the moment the newcomer upgrades,
+     which is TerminalDataPlane.UpgradeAsync's takeover doing exactly what it is meant to. Counting that
+     close as a fresh failure schedules a retry against a socket that has just succeeded, and the
+     takeover then aborts *that* one, whose close schedules the next — a loop with no fixed point, in
+     which the terminal reconnects every second or so forever and the banner is up for most of it. Every
+     handler below asks whether it is still the page's socket before it does anything.
+
+  2. AN ATTEMPT THAT NEVER FINISHES IS A FAILURE TOO. See HANDSHAKE_TIMEOUT_MS.
+
+  3. COMING BACK IS A REASON TO TRY, NOT ONLY THE CLOCK. The retry is a setTimeout chain, and a chain is
+     precisely what a WebView is entitled to stop running. Chromium throttles timers in a page nobody is
+     looking at — down to once a minute once it has been hidden five minutes — and a renderer that is
+     frozen, or reclaimed and not yet reloaded, runs none of them at all. So the socket drops while nobody
+     is watching, the banner goes up, the retry is scheduled, and the retry is then the one thing not
+     running: coming back shows a terminal that says it is reconnecting and, for as long as that lasts,
+     is not.
+
+     The phone is where this is easiest to reach, because leaving the terminal for another screen
+     collapses its WebView to GONE — see createSession's note on the GPU context — and a WebView with no
+     surface is a page the platform may treat as hidden. Which of the two mechanisms actually bit is not
+     established here, and does not need to be: both end with a timer that will not run, and the fix is
+     not to guess at either but to stop depending on the timer alone.
+
+     Hence the wake-ups at the bottom of this file. What they add is not a faster retry; it is a retry
+     driven by the one thing that cannot be throttled, which is the user arriving.
+*/
+
 /** @type {number | null} */
 let reconnectTimer = null;
+
+/** @type {number | null} */
+let handshakeTimer = null;
+
 let reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
 
 /**
@@ -608,16 +664,86 @@ function scheduleReconnect() {
   reconnectDelay = Math.min(reconnectDelay * 2, RECONNECT_MAX_DELAY_MS);
 }
 
+/**
+ * Tries the socket again now, if it is down.
+ *
+ * The entry point for "somebody is looking at this page again", and it has to be safe to call as often
+ * as that happens — which on the desktop is every time the window is clicked. A socket that is up makes
+ * this nothing at all.
+ *
+ * An attempt still in CONNECTING is left alone rather than restarted: it may be about to succeed, and
+ * the one that is not is already the handshake watchdog's to give up on.
+ */
+function reconnectIfDown() {
+  if (socket !== null
+    && (socket.readyState === WebSocket.OPEN || socket.readyState === WebSocket.CONNECTING)) {
+    return;
+  }
+
+  // Whatever the timer was going to do, this is doing now. Left pending it would land on top of the
+  // socket this call is about to open, and the takeover that followed is the loop rule 1 describes.
+  if (reconnectTimer !== null) {
+    clearTimeout(reconnectTimer);
+    reconnectTimer = null;
+  }
+
+  // Back to the quick attempt. The wait grew to space out retries during an outage nobody was watching,
+  // and being called at all means somebody is watching now.
+  reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
+
+  connect();
+}
+
 function connect() {
   const token = root.dataset.token;
   const url = root.dataset.socket;
 
+  /*
+    Whatever was attached is abandoned here, and closed rather than dropped: the host takes the socket
+    over regardless, but one left open is a connection it has to abort and an event this page then has to
+    ignore. Cleared out of `socket` before the close, so that every handler — including that close,
+    whenever it lands — can already tell the attempt is no longer the page's.
+  */
+  const abandoned = socket;
+  socket = null;
+  abandoned?.close();
+
   // The token travels as a subprotocol rather than a query parameter, which keeps it out of
   // anything that logs URLs.
-  socket = new WebSocket(url, ['dodossh.terminal.v1', `token.${token}`]);
-  socket.binaryType = 'arraybuffer';
+  const pending = new WebSocket(url, ['dodossh.terminal.v1', `token.${token}`]);
+  pending.binaryType = 'arraybuffer';
+  socket = pending;
 
-  socket.addEventListener('open', () => {
+  /** Whether this attempt is still the page's, rather than one a later connect() has replaced. */
+  const isCurrent = () => socket === pending;
+
+  const forgetHandshakeTimer = () => {
+    if (handshakeTimer !== null) {
+      clearTimeout(handshakeTimer);
+      handshakeTimer = null;
+    }
+  };
+
+  forgetHandshakeTimer();
+
+  handshakeTimer = setTimeout(() => {
+    handshakeTimer = null;
+
+    // Still CONNECTING with nothing on its way. Only the retry is arranged here; abandoning the attempt
+    // is left to the connect() that retry runs, which is the one place a socket is replaced.
+    if (isCurrent() && pending.readyState === WebSocket.CONNECTING) {
+      scheduleReconnect();
+    }
+  }, HANDSHAKE_TIMEOUT_MS);
+
+  pending.addEventListener('open', () => {
+    // A replaced attempt cannot reach here — connect() closes what it abandons, and a socket closed
+    // while connecting never opens — so this is a guard against the ordering rather than a live case.
+    if (!isCurrent()) {
+      return;
+    }
+
+    forgetHandshakeTimer();
     setTransportStatus('');
 
     // Back to the quick attempt for whatever the next failure turns out to be. Kept slow between
@@ -625,14 +751,25 @@ function connect() {
     reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
   });
 
-  socket.addEventListener('message', (event) => handleFrame(event.data));
+  pending.addEventListener('message', (event) => {
+    if (isCurrent()) {
+      handleFrame(event.data);
+    }
+  });
 
   // Both close and error retry. They are not the same event on every failure — a socket that never
   // opens can fire only 'error', one that opens and later drops fires only 'close' — and the host
   // side of this same problem (TerminalDataPlane.UpgradeAsync's takeover) is exactly why retrying is
   // safe: whichever attempt eventually reaches the host, a fresh valid upgrade always wins the socket.
-  socket.addEventListener('close', scheduleReconnect);
-  socket.addEventListener('error', scheduleReconnect);
+  const retry = () => {
+    if (isCurrent()) {
+      forgetHandshakeTimer();
+      scheduleReconnect();
+    }
+  };
+
+  pending.addEventListener('close', retry);
+  pending.addEventListener('error', retry);
 }
 
 // One observer for the whole root rather than one per pane: resizes arrive in bursts while a
@@ -645,4 +782,30 @@ new ResizeObserver(() => {
 
 window.addEventListener('beforeunload', () => socket?.close());
 
+/*
+  The ways this page finds out somebody is looking at it again — rule 3 at the top of the transport
+  section. All three end in the same check, and that check is what makes them safe to be as noisy as they
+  are: with a healthy socket every one of them does nothing.
+
+  'visibilitychange' is the phone's. A WebView collapsed to GONE is a hidden page, so coming back to the
+  terminal screen is the event that says so, and it is the same event Chromium lifts its own throttling
+  on — this page simply does not wait to be asked twice.
+
+  'focus' is the desktop's, where the page is *not* marked hidden while the WebView is collapsed
+  (measured; see docs/platform-flags.md) but a window left in the background for hours has had its timers
+  throttled all the same. It fires when the terminal takes the keyboard back, which is the same gesture.
+
+  'online' is neither head's ordinary case, because the socket is loopback and has nothing to do with the
+  network — but the event does follow a machine coming back from sleep, and a page with a dead socket has
+  no reason to ignore any hint that the world has moved.
+*/
+document.addEventListener('visibilitychange', () => {
+  if (!document.hidden) {
+    reconnectIfDown();
+  }
+});
+
+window.addEventListener('focus', reconnectIfDown);
+window.addEventListener('online', reconnectIfDown);
+
 connect();