From 4feca75da70d7eec5cf5657cc7bb387efd6b5676 Mon Sep 17 00:00:00 2001
From: Brennan Benson <79079362+brennanb2025@users.noreply.github.com>
Date: Fri, 28 Aug 2026 02:48:05 -0700
Subject: [PATCH] test(secrets): pin the once-guard against a late window
 reveal
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The fallback can report first and the window reveal arrive after it; without
the guard that probes the keyring a second time, blocking the main thread just
as the user starts interacting. No existing case covered that order — removing
the guard left all six tests green.
---
 .../host/deferred-secret-protection-report.test.ts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/src/main/host/deferred-secret-protection-report.test.ts b/src/main/host/deferred-secret-protection-report.test.ts
index 2e70d5268a0..67ee0eb755b 100644
--- a/src/main/host/deferred-secret-protection-report.test.ts
+++ b/src/main/host/deferred-secret-protection-report.test.ts
@@ -132,6 +132,20 @@ describe('scheduleSecretProtectionGapReport', () => {
     expect(probes).toBe(1)
   })
 
+  it('does not probe again when the window reveals after the fallback already reported', () => {
+    // Why this order and not the reverse: a GPU that presents late reveals the window
+    // after the fallback has already reported, and a second blocking keyring probe would
+    // freeze the main thread exactly as the user starts interacting.
+    schedule()
+    const window = createWindow()
+    vi.advanceTimersByTime(15_100)
+    drain()
+    expect(probes).toBe(1)
+    window.reveal()
+    drain()
+    expect(probes).toBe(1)
+  })
+
   it('reports inline in headless serve, before the runtime is advertised as ready', () => {
     // Why not deferred: serve opens no window, so the fallback would fire only after
     // clients could already have paired, and a frozen main thread reads as a dead host.