fix(windows): 静默启动 #468 最后一公里 - 前端兜底

[appergb]

User description

closes#468 — 详见 PR description (Rust 端 #471 修了 setup + single-instance 后，前端 App.tsx 仍无条件 IPC show 把窗口拉出来；现在 show 前读 startMinimized 兜底)

---

PR Type

Bug fix

---

Description

• Respect startMinimized before showing

• Preserve fallback when settings read fails

• Stop frontend relaunch from reopening

---

Diagram Walkthrough

flowchart LR
A["App startup"] -- "read settings" --> B["getSettings()"]
B -- "startMinimized=true" --> C["Skip show()"]
B -- "read fails" --> D["Fallback to show window"]
C -- "preserve silent launch" --> E["Main window stays hidden"]
D -- "keep existing behavior" --> E

Loading

File Walkthrough

	Relevant files
Bug fix	App.tsx Guard startup show by settings openless-all/app/src/App.tsx Imports getSettings for startup prefs Checks startMinimized before window show Skips relaunch window reveal when minimized Keeps legacy show fallback on read errors +21/-8

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 468 - PR Code Verified Compliant requirements: 启动时在前端读取 startMinimized，为 true 时跳过 show() Requires further human verification: 需要在 Win11 真机上确认登录启动和手动二次启动都不会再弹出主窗口。

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ No major issues detected

[appergb]

@claude 请审查这个 PR。

简短说明：

• fix(windows): 修复 #466 / #468 / #469 / #470 四个 Windows bug #471 在 Rust 端两条 show 路径都加了 start_minimized 抑制，用户日志确认 Rust 正确没问题
• 但用户在 1.3.4-3 Win11 真机仍然「开机进桌面那一刻主窗口就出来」
• 定位：App.tsx mount 时一条 useEffect 通过 IPC getCurrentWindow().show() 把窗口拉出来，绕过 Rust suppression，Rust log 完全看不到
• 修法：show 前读 prefs.startMinimized，true 就 return
• pr_agent 已一轮通过（No major issues / No security concerns），三平台 CI 全绿

主要关注点：

1. App.tsx 改成异步 IIFE 之后 cancelled 标志处理是否正确（getSettings 之后再判 cancelled，再 dynamic import）
2. getSettings 失败时走原 show 路径是否合理（保留 [windows] hotkey hook 永远 starting 时启动 gate 死锁，主窗口卡 "正在启动" 灰屏 #163 的「权限探测死锁→前端兜底拉首屏」语义）
3. 跨平台：这条 useEffect 在 mac 上也跑，prefs.startMinimized 在 mac 上意味着什么、有没有副作用

辛苦。

[claude]

Claude finished @appergb's task in 2m 48s —— View job

---

PR #474 代码审查

• 读取变更文件和 git diff
• 分析 cancelled 标志处理正确性
• 分析 getSettings 失败回退路径合理性
• 分析跨平台（macOS）副作用
• 输出完整审查意见

---

总体结论

修复思路正确，针对 issue #468 的最后一公里路径（前端 IPC show 绕过 Rust 抑制）定位准确。三个关注点的详细分析如下。

---

关注点 1：cancelled 标志处理

结论：基本正确，有一个无害的检测空隙。

当前检测点：

requestAnimationFrame → [cancelled check] → getSettings() ↓
prefs.startMinimized=true → return ✓
prefs.startMinimized=false → ⬇
import('@tauri-apps/api/window')
↓
[cancelled check] ← 第二次检测点
↓
isVisible() → show()

问题所在：在 getSettings() resolve（startMinimized=false 路径）之后到 dynamic import 完成之前，没有 cancelled 检测。若组件恰好在这一时间窗口卸载，IIFE 会继续执行 dynamic import，再到 if (cancelled) return 才停下——也就是说 dynamic import 会被触发但 show() 不会执行。

为什么不是真正的 Bug：

1. @tauri-apps/api/window 是静态依赖，通常已被 bundler 加载，dynamic import 几乎同步完成；
2. 即便有竞争，cancelled 在 show() 之前仍然会被正确检测；
3. 该 useEffect 依赖 [gate, os]，在应用生命周期内 os 永不变，gate 只从 checking → ready/onboarding 单向转换，重新触发（从而产生竞争）的概率极低。

如果追求最严格的写法，可在 getSettings() 之后加一次检测：

constprefs=awaitgetSettings();if(cancelled)return;// ← 可加if(prefs.startMinimized)return;

不加也不影响正确性，看项目风格偏好。

---

关注点 2：getSettings 失败时走原 show 路径

结论：合理，保留了 #163 的兜底语义。

}catch(err){console.warn('[startup] read startMinimized failed, falling back to show',err);}// 继续走 show 路径

失败时默认行为是"展示窗口"而非"静默"，这是正确的 fail-safe 方向：

• [windows] hotkey hook 永远 starting 时启动 gate 死锁，主窗口卡 "正在启动" 灰屏 #163 的语义：hotkey hook 被 EDR/UAC 拦住 → getHotkeyStatus 死锁 → 超时后 setGate('ready') → 这条 useEffect 触发。此时如果 getSettings 也失败（例如权限问题），窗口仍然要展示，让用户能进 Permissions 页看错误；
• **替代方案（失败时静默）的问题：如果 getSettings IPC 失败而静默跳过 show，用户会看到透明/空白窗口且无法交互，这正是 [windows] hotkey hook 永远 starting 时启动 gate 死锁，主窗口卡 "正在启动" 灰屏 #163 要解决的问题。

唯一值得商量的地方：失败时也许应读取 mockSettings 的默认值 startMinimized: false 而非直接 fallback，但效果等价，且当前写法更显式，更容易调试。

---

关注点 3：跨平台 —— macOS 副作用

结论：存在一个轻微的设计风险，实际影响极低，但建议后续修复。

当前问题：Settings UI 中 startMinimized toggle 没有平台限制（Settings.tsx:600-604，AutostartRow 也跨平台），Mac 用户可以将其打开。打开后，这条 useEffect 在 macOS 上同样会 return 而跳过 show()。

macOS 的 Rust 端 setup()不做 startMinimized 抑制（这是 Windows 专属修复），所以 macOS 在正常启动时窗口由 Rust 端 show() 打开。但若由于某种原因（边缘场景）窗口在 webview 加载时处于不可见状态，这个前端兜底 show 本是最后的保险——新代码在 startMinimized=true 时把这个保险也禁用了。

场景	旧行为	新行为
Mac + startMinimized=false（99.9% 用户）	isVisible() 检测后 NOP	同左，多一次 IPC 读 prefs
Mac + startMinimized=true（极少数）	若窗口可见则 NOP，不可见则 show	直接跳过 show，窗口可能卡在不可见状态
Windows + startMinimized=true	show() 被调用（Bug）	正确跳过 ✓

建议的改法：将 startMinimized 检测限定到 Windows，与现有平台分支保持一致：

if(os==='win'){try{constprefs=awaitgetSettings();if(prefs.startMinimized)return;}catch(err){console.warn('[startup] read startMinimized failed, falling back to show',err);}}

这消除了对 macOS 的任何影响，且逻辑更清晰：静默启动是 Windows autostart 特性，不适用于 macOS 的 gate 流程。

Fix this →

---

其他小观察

1. 性能：现在所有平台的启动 show 路径都多了一次 get_settings IPC 调用。在正常情况下这是 <2ms，可忽略。但如果 get_settings 在特定环境下较慢（如首次启动磁盘 IO），会轻微延迟窗口显示。Windows + startMinimized=false 的用户也受影响，虽然实际观感上几乎察觉不到。

2. 注释质量：注释写得很清楚，明确解释了为什么要做这件事（Rust log 看不到、[windows] 启动时静默运行功能在 Win11 失效 #468 最后路径、[windows] hotkey hook 永远 starting 时启动 gate 死锁，主窗口卡 "正在启动" 灰屏 #163 语义），这是好的。

---

是否可以合并

Windows startMinimized=true 的修复逻辑正确，CI 全绿，可以合并。

macOS 的 os === 'win' 守卫是锦上添花的防御性改进，不影响当前 99.9% 用户，可以在这个 PR 里顺手加上，也可以留到后续 cleanup。由你们决定。