@bobfrankston/rmfmail 1.2.282 → 1.2.284

package/bin/mailx.ts

@@ -474,7 +474,17 @@ function readInstanceFile(): InstanceFile | null {
 function writeInstanceFile(pid: number, childPids: number[] = []): void {
     try {
         fs.mkdirSync(path.dirname(__instanceFile), { recursive: true });
-        const payload: InstanceFile = { pid, version: __selfVersion, startedAt: Date.now(), childPids };
+        // startedAt must survive a childPids update. It was recomputed on every
+        // write, and since every popup and popout window rewrites this file,
+        // the field reported the last window event rather than when the daemon
+        // started — actively misleading when diagnosing "how long has this been
+        // up" or "which of these daemons is the old one" (it cost a wrong turn
+        // on 2026-08-27). Keep the existing value whenever the PID is unchanged.
+        const prev = readInstanceFile();
+        const startedAt = prev && prev.pid === pid && typeof prev.startedAt === "number"
+            ? prev.startedAt
+            : Date.now();
+        const payload: InstanceFile = { pid, version: __selfVersion, startedAt, childPids };
         fs.writeFileSync(__instanceFile, JSON.stringify(payload, null, 2));
     } catch { /* non-fatal */ }
 }
@@ -543,6 +553,17 @@ const __handoffStamp = path.join(path.dirname(__instanceFile), "last-handoff.sta
 function touchHandoffStamp(): void {
     try { fs.writeFileSync(__handoffStamp, String(Date.now())); } catch { /* */ }
 }
+
+/** "Someone launched me while you are already running — show yourself."
+ *
+ *  A file rather than a socket, for the same reason the mailto and share
+ *  handoffs use one: the launching process is a fresh node that will exit in
+ *  milliseconds, and the daemon is already watching this directory. The daemon
+ *  side deletes it and sends the native focus command. */
+const __activateFile = path.join(path.dirname(__instanceFile), "pending-activate.json");
+function requestActivate(): void {
+    try { fs.writeFileSync(__activateFile, JSON.stringify({ at: Date.now(), fromPid: process.pid })); } catch { /* */ }
+}
 if (!isDaemon && !__isCommandInvocation && !__keepOthers) {
     // Handoff launches must NOT replace a live daemon. rmfshare.exe (share
     // sheet) and rmfmailto.exe (mailto links) write a pending file and spawn
@@ -567,12 +588,36 @@ if (!isDaemon && !__isCommandInvocation && !__keepOthers) {
             }
         }
     }
-    // Replace-on-launch: any rmfmail daemon already running gets killed and
+    // Activate-on-launch: launching the SAME version that is already running
+    // raises the window that exists instead of replacing it.
+    //
+    // Replace-on-launch (below) was written for the upgrade case — an older or
+    // orphaned daemon surviving a partial upgrade and leaving two windows on
+    // two versions. But it fired on EVERY launch, including the ordinary one:
+    // press the taskbar icon, the new process SIGTERMs the running daemon, its
+    // window vanishes, and seconds later a fresh one appears. From the outside
+    // that reads as the app flickering out of existence for no reason (Bob
+    // 2026-08-26: "why does it show and disappear... you should still put me in
+    // the running version when I press the icon on the task bar").
+    //
+    // instance.json already records the running version, so the two cases are
+    // distinguishable without guessing: same version means the user wants the
+    // app, so surface it; a different version means an upgrade landed and the
+    // old daemon must go. `-another` still opts out entirely, and every handoff
+    // path above still returns before reaching here.
+    {
+        const inst0 = readInstanceFile();
+        if (inst0 && pidIsMailx(inst0.pid) && inst0.pid !== process.pid && inst0.version === __selfVersion) {
+            requestActivate();
+            console.log(`rmfmail: already running (PID ${inst0.pid}, v${inst0.version}) — raising its window`);
+            process.exit(0);
+        }
+    }
+
+    // Replace-on-launch: a daemon running a DIFFERENT version gets killed and
     // the new one takes over. instance.json only tracks ONE PID — older or
     // orphaned daemons can survive a partial upgrade and leave the user with
-    // multiple windows on different versions. Sweep PowerShell for any
-    // rmfmail-looking node process and kill it (unconditionally — version
-    // match alone isn't enough; we always want exactly one daemon).
+    // multiple windows on different versions.
     const myPid = process.pid;
     const killedPids: number[] = [];
     const inst = readInstanceFile();
@@ -633,6 +678,29 @@ if (!verbose && !isDaemon && !process.argv.slice(2).some(a => /^-/.test(a))) {
         windowsHide: true,
     });
     child.unref();
+    // Claim the instance slot for the child NOW, before we exit.
+    //
+    // Without this there is a multi-second hole in which no instance exists on
+    // paper: we spawn a detached daemon and exit immediately, but the daemon
+    // does not register itself until it has built the store, started the
+    // popout server and opened its window — several seconds later. Any launch
+    // arriving inside that hole reads instance.json, sees nothing alive, and
+    // starts ANOTHER daemon. That is how three of them ended up running at
+    // once on 2026-08-26, spawned 4 and 5 seconds apart (PIDs 1452, 34012,
+    // 94964), each with its own window, only one of them in instance.json —
+    // which is also why nothing came to the front and why replace-on-launch
+    // could never clean them up: it only ever knew about the last one to
+    // register (Bob: "this does not look like a single instance ... but not
+    // one of the windows came to the front").
+    //
+    // The child is alive from the moment spawn returns, and pidIsMailx is a
+    // liveness check, so the claim is valid immediately. If the child dies
+    // during boot the existing stale-PID check clears it on the next launch,
+    // and when the daemon does reach its own registration it writes the same
+    // PID again — no conflict. A launch that lands during boot now takes the
+    // activate path and drops pending-activate.json, which the daemon picks up
+    // when it starts watching. (Claude Code 2026-08-27)
+    if (typeof child.pid === "number") writeInstanceFile(child.pid, []);
     process.exit(0);
 }
 
@@ -2984,6 +3052,43 @@ RFC 5322 with CRLF line endings. Bodies are quoted-printable encoded (readable i
         }
     }
 
+    // Activation requests. A second launch of the SAME version (taskbar icon,
+    // Start menu, a double-clicked shortcut) drops pending-activate.json and
+    // exits instead of replacing us; this is the half that answers it by
+    // bringing the existing window to the front. Same fs.watch + native
+    // control-message shape as the mailto and share handoffs below.
+    //
+    // Without this the launcher would have nothing to hand off TO, and
+    // "already running — raising its window" would be a lie: the process would
+    // exit and the user would be left staring at whatever they were looking at
+    // before, which is worse than the restart it replaced.
+    {
+        try {
+            const dir = path.dirname(__activateFile);
+            const baseName = path.basename(__activateFile);
+            fs.mkdirSync(dir, { recursive: true });
+            // A request that landed while we were still booting — the watch
+            // below can only see files that arrive after it is installed.
+            if (fs.existsSync(__activateFile)) {
+                try { fs.unlinkSync(__activateFile); } catch { /* */ }
+                handle.send({ _msgerWindow: "focus" });
+            }
+            fs.watch(dir, (_event, filename) => {
+                if (filename !== baseName) return;
+                if (!fs.existsSync(__activateFile)) return;
+                // Delete FIRST. fs.watch fires twice for one write on Windows
+                // (rename + change), and a second focus command is harmless but
+                // the unlink is what makes the second pass a no-op.
+                try { fs.unlinkSync(__activateFile); } catch { return; }
+                touchHandoffStamp();
+                console.log("  [activate] second launch asked for the window — raising it");
+                handle.send({ _msgerWindow: "focus" });
+            });
+        } catch (e: any) {
+            console.error(`  [activate] watch setup failed: ${e.message}`);
+        }
+    }
+
     // Pending Windows-share handler (C46). Same two-path pickup as mailto
     // above: the client's startup consumePendingShare poll covers the
     // "rmfshare.exe spawned us" race; this fs.watch covers shares that land

package/client/app.bundle.js

@@ -3108,11 +3108,11 @@ async function showMessage(accountId, uid, folderId, specialUse, isRetry = false
     }
     bodyEl.innerHTML = "";
     const spam = msg.spamScore;
-    if (spam && Number.isFinite(spam.score)) {
-      const level = spam.flagged ? "high" : spam.score >= spam.threshold / 2 ? "mid" : "low";
+    if (spam && Number.isFinite(spam.score) && (spam.flagged || spam.score >= spam.threshold / 2)) {
+      const level = spam.flagged ? "high" : "mid";
       const chip = document.createElement("div");
       chip.className = `mv-spamscore mv-spamscore-${level}`;
-      chip.title = level === "high" ? "Your mail server scored this at or above its spam threshold and flagged it." : level === "mid" ? "Below your server's spam threshold, but more than halfway to it." : "Well below your mail server's spam threshold.";
+      chip.title = level === "high" ? "Your mail server scored this at or above its spam threshold and flagged it." : "Below your server's spam threshold, but more than halfway to it.";
       chip.textContent = `spam score ${spam.score} of ${spam.threshold}`;
       bodyEl.appendChild(chip);
     }