Revert "fix(stealth): ..." — speculative follow-ups to #509

Reverts 86b5ad9 and 73dda11, restoring electron/WindowHelper.ts and the
overlay tests to exactly the state PR #509 merged in.

Neither commit was backed by a defect I could actually demonstrate:

- The win32 skip on the chrome re-push rested on "a value-identical
  setContentProtection call causes DWM affinity churn", which is a comment
  in this repo, not something verified on Windows from here. It also
  narrowed a protective write on a stealth path — the wrong direction to
  move on an unverified premise.

- The opacity-shield flush fixed a real control-flow gap (minimizeWindow /
  closeWindow discard a pending setOpacity(1)) but I never showed the race
  is reachable: it needs a minimize or close-to-tray IPC landing inside the
  60ms shield window, while the launcher is transparent or hidden.

The nulling of this.opacityTimeout only mattered as support for the flush,
so it goes with it.

The one finding that WAS demonstrated — the vacuous positive assertions in
OverlayAlwaysContentProtected.test.mjs, proven by a mutation probe that
reintroduced the leak at both creation sites and still gave 8/8 green — is
in 63a4fe9 and stays, since it came in with the PR.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Si93L7isjy1GFkqzjb7gJy

Author: Hardening v2.7

electron/WindowHelper.ts

@@ -279,33 +279,12 @@ export class WindowHelper {
     // default), re-exposing it via `NSWindowSharingReadOnly` and overriding the
     // unconditional `NSWindowSharingNone` the native stealth module applies to
     // exactly these three windows. Force it on for them regardless of `enable`.
-    //
-    // Skipped on Windows, deliberately. The chrome is already `true` from
-    // creation (createWindow / createOverlayAuxWindows) and on every show
-    // (switchToOverlay, both branches), and NOTHING in this codebase ever
-    // passes `false` for these three — so on win32 this write is always
-    // value-identical, and identical writes are exactly what the dedupe guard
-    // in setContentProtection() exists to avoid: repeated DWM affinity churn
-    // leaves the HWND in a transient black/blank frame state for a few hundred
-    // ms (see SetContentProtectionDedupe.test.mjs). Before the always-protect
-    // fix this write was value-CHANGING on every undetectable toggle, so it
-    // paid for itself; now it would only blank the overlay mid-meeting when
-    // the user flips undetectable mode.
-    //
-    // It is still required off win32: reassertContentProtection() routes here
-    // after app.dock.hide()/show(), and that macOS activation-policy flip makes
-    // WindowServer re-evaluate each NSWindow and silently reset its
-    // sharingType. There the re-push is the whole point — the in-memory value
-    // is already correct, so only an unconditional write restores the OS flag.
-    // Windows has no equivalent policy flip.
-    if (process.platform !== 'win32') {
-      const overlayChrome = [this.overlayWindow, this.pillWindow, this.toggleWindow];
-      overlayChrome.forEach((win) => {
-        if (win && !win.isDestroyed()) {
-          win.setContentProtection(true);
-        }
-      });
-    }
+    const overlayChrome = [this.overlayWindow, this.pillWindow, this.toggleWindow];
+    overlayChrome.forEach((win) => {
+      if (win && !win.isDestroyed()) {
+        win.setContentProtection(true);
+      }
+    });
     // The launcher and popover catcher are not meeting chrome; they follow the
     // undetectable-mode toggle (the launcher is the main window shown outside a
     // meeting, and the native module deliberately does NOT force-hide it).
@@ -2309,11 +2288,6 @@ export class WindowHelper {
 
         if (this.opacityTimeout) clearTimeout(this.opacityTimeout);
         this.opacityTimeout = setTimeout(() => {
-          // Mark the shield spent. Without this the field holds an
-          // already-fired Timeout forever, so cancelOpacityShield()'s
-          // "nothing pending" early return never fires and every later
-          // minimize/close runs a pointless restore pass.
-          this.opacityTimeout = null;
           if (this.overlayWindow && !this.overlayWindow.isDestroyed()) {
             this.overlayWindow.setOpacity(1);
             this.pillWindow?.setOpacity(1);
@@ -2412,8 +2386,6 @@ export class WindowHelper {
 
         if (this.opacityTimeout) clearTimeout(this.opacityTimeout);
         this.opacityTimeout = setTimeout(() => {
-          // Mark the shield spent — see the overlay branch above.
-          this.opacityTimeout = null;
           if (this.launcherWindow && !this.launcherWindow.isDestroyed()) {
             this.launcherWindow.setOpacity(1);
             if (!inactive) this.launcherWindow.focus();
@@ -2537,48 +2509,10 @@ export class WindowHelper {
     menu.popup({ window: win, x: point.x, y: point.y });
   }
 
-  /**
-   * Cancel a pending opacity-shield timer WITHOUT stranding its windows at
-   * opacity 0.
-   *
-   * The Windows opacity shield (switchToOverlay / switchToLauncher) shows a
-   * window at opacity 0 and restores it 60ms later, once DWM has applied the
-   * capture-exclusion flag, so the first frame can't leak. A bare
-   * `clearTimeout` drops that restore on the floor: a minimize or close landing
-   * inside those 60ms left the shielded windows shown-but-fully-transparent
-   * until the next switch re-set their opacity. Flush the restore instead of
-   * discarding it — setting opacity 1 on a window that is about to be minimized
-   * or closed is harmless; leaving one stuck invisible is not.
-   *
-   * `isVisible()` is the guard that keeps this from fighting hideMainWindow,
-   * which deliberately zeroes opacity on win32 before hide() so a capture frame
-   * during the hide can't leak the chrome. Those windows are hidden by then, so
-   * they are skipped here and their opacity is re-set by the next show.
-   *
-   * NOT for the shield's own arm sites: those call setOpacity(0) and then clear
-   * the previous timer, so flushing there would undo the shield they just set.
-   */
-  private cancelOpacityShield(): void {
-    if (!this.opacityTimeout) return;
-    clearTimeout(this.opacityTimeout);
-    this.opacityTimeout = null;
-    const shielded = [
-      this.launcherWindow,
-      this.overlayWindow,
-      this.pillWindow,
-      this.toggleWindow,
-    ];
-    for (const win of shielded) {
-      if (win && !win.isDestroyed() && win.isVisible()) {
-        win.setOpacity(1);
-      }
-    }
-  }
-
   public minimizeWindow(): void {
     const win = this.launcherWindow;
     if (!win || win.isDestroyed()) return;
-    this.cancelOpacityShield();
+    if (this.opacityTimeout) clearTimeout(this.opacityTimeout);
     win.minimize();
   }
 
@@ -2834,10 +2768,7 @@ export class WindowHelper {
   public closeWindow(): void {
     const win = this.launcherWindow;
     if (!win || win.isDestroyed()) return;
-    // Flush, don't drop: on Windows/Linux this hides to tray rather than
-    // quitting, so a discarded shield restore would strand the overlay chrome
-    // at opacity 0 for the rest of the session.
-    this.cancelOpacityShield();
+    if (this.opacityTimeout) clearTimeout(this.opacityTimeout);
     // On Windows/Linux the 'close' event listener intercepts this
     // and hides to tray unless the app is actually quitting.
     win.close();

electron/audio/__tests__/OpacityShieldCancelRestores.test.mjs

@@ -123,7 +123,7 @@ test('applyContentProtection maps at least two window groups (chrome + followers
 });
 
 for (const win of OVERLAY_CHROME) {
-    test(`applyContentProtection protects ${win} with a literal true, never \`enable\``, () => {
+    test(`applyContentProtection protects ${win} unconditionally (setContentProtection(true))`, () => {
         const owning = groups.filter((g) => g.members.includes(win));
         assert.ok(
             owning.length > 0,
@@ -135,38 +135,14 @@ for (const win of OVERLAY_CHROME) {
                 g.arg,
                 'true',
                 `BUG: ${win} receives \`setContentProtection(${g.arg})\` in applyContentProtection, ` +
-                `not \`true\`. The overlay chrome's protection must not depend on the mode — coupling it to ` +
+                `not \`true\`. The overlay chrome must be protected unconditionally — coupling it to ` +
                 `\`enable\` (undetectable mode) re-exposes the overlay in screen shares whenever ` +
                 `undetectable mode is off (its default).`,
             );
         }
     });
 }
 
-test('the chrome re-push in applyContentProtection still runs on macOS', () => {
-    // The chrome loop is skipped on win32 (there the write is always
-    // value-identical, and identical writes cause the DWM affinity churn
-    // SetContentProtectionDedupe.test.mjs exists to prevent). It must NOT be
-    // skipped off win32: reassertContentProtection() routes through here after
-    // app.dock.hide()/show(), and that macOS activation-policy flip makes
-    // WindowServer re-evaluate each NSWindow and silently reset its sharingType.
-    // The in-memory value is still correct, so only an unconditional re-push
-    // restores NSWindowSharingNone. Narrowing this gate to exclude darwin —
-    // or dropping the chrome from applyContentProtection altogether — silently
-    // un-protects the overlay after every dock toggle.
-    const beforeChrome = body.slice(0, body.indexOf('const overlayChrome'));
-    const gates = beforeChrome.match(/process\.platform\s*[!=]==\s*'[a-z0-9]+'/g) ?? [];
-    for (const gate of gates) {
-        assert.equal(
-            gate,
-            "process.platform !== 'win32'",
-            `BUG: the overlay-chrome re-push in applyContentProtection is gated on \`${gate}\`. ` +
-            `It must run on darwin — reassertContentProtection() relies on it to restore ` +
-            `NSWindowSharingNone after app.dock.hide()/show() resets sharingType.`,
-        );
-    }
-});
-
 test('applyContentProtection keeps the launcher on the undetectable-mode toggle (enable)', () => {
     // Sanity that the split is real: the launcher is NOT meeting chrome and must
     // still follow the toggle, so we are not just blanket-forcing everything true.