[windows/window] 修复悬窗透明遮罩和 Windows 白边

[Cooper-X-Oak]

This was generated by AI during triage.

Parent

#478

Triage

• Category: bug
• State: ready-for-agent
• Requested state label: ready-for-agent
• Requested repository labels (not applied by this run due label permissions): bug, windows, priority: high

What to build

修复 Windows 悬窗主体内容区异常透出底层应用内容的问题，并处理 Windows App 两侧明显白边。该任务需要先定位透明/白边来自 Tauri window transparency、WebView2 背景、窗口特效、CSS 背景层级，还是组件布局边界，而不是直接叠加猜测式 CSS。

Acceptance criteria

• Windows 下打开 OpenLess 悬窗后，主体内容区不再异常透出底层应用内容。
• 默认提示页、录音中状态、结果展示状态的背景透明度符合设计预期，正文清晰可读。
• 悬窗圆角、边框、阴影、底部状态栏没有异常透明层叠。
• App 主窗口两侧非预期白边消失，或被明确解释为设计/平台约束并记录后续处理。
• 修复 PR 附带 before/after 截图或截图路径。

Blocked by

None - can start immediately.

Evidence

• [ui] 悬窗透明遮罩异常透出底层内容 #475: Windows 环境下打开悬窗后，悬窗主体内容区出现异常透明遮罩，底层应用内容透过正文区域显示出来；Reporter 提供 UI透明遮罩的bug.png 和日志。
• 希望支持自动加入词典/OCR 导入，并修复 Windows 窗口卡死和白边问题 #445: Windows 系统的 App 两侧有明显白边。

Expected / Actual

Expected: 悬窗主体区域应当有明确、可读的背景层；窗口边缘与设计一致，不暴露非预期底层内容或白边。

Actual: 用户截图显示悬窗中央空白区域、底部状态栏和底层应用内容发生透出，另有主窗口白边反馈。

Validation gate

• Windows 上复测默认提示页、录音中、结果展示三个状态。
• 保存 before/after 截图到 PR 证据路径。
• 运行：npm run build。
• 如改动 Tauri window config，补充 Windows 本地启动验证并记录 openless.log 中窗口创建路径。

[Cooper-X-Oak]

This was generated by AI during triage.

Evidence Update - local fix

Diagnosis:

• The main window is configured with transparent: true so platform vibrancy/Mica remains possible.
• Global html, body, #root were also fully transparent for every webview.
• On Windows, especially when Mica is unavailable or WebView2 transparent composition is unstable, the semi-transparent React glass layers can blend directly with the app behind OpenLess. That explains the reported "content area leaking underlying app" and the visible side/edge artifacts.

Targeted fix:

• src/main.tsx now marks each webview before React renders:
  • data-openless-window="main|capsule|qa"
  • data-openless-platform="win|mac|linux"
• src/styles/global.css gives only main + win an internal opaque canvas: #f5f5f7.
• Capsule and QA keep the shared transparent WebView baseline, so the recording pill / floating QA window behavior is not flattened.
• macOS main-window vibrancy is not covered by this Windows-only CSS branch.

Validation passed:

cd openless-all/app
node .\scripts\windows-main-opaque-canvas.test.mjs
npm run build

Screenshot evidence saved locally for PR packaging:

• .artifacts/windows-beta/482/main-window-opaque-canvas.png
• .artifacts/windows-beta/482/capsule-window-transparent-scope.png
• .artifacts/windows-beta/482/qa-window-transparent-scope.png

State: locally complete for the first Windows beta high-frequency pass. Residual risk is exact reporter-machine WebView2/DWM composition, which should be handled as post-release feedback under the current queue policy.

[Cooper-X-Oak]

This was generated by AI during triage.

Evidence update - 2026-05-18 real-machine rerun

The reporter screenshot remains a valid bug signal for Windows transparent overlay / white bleed. The current local rerun gives a mixed result:

Passed

node .\scripts\windows-main-opaque-canvas.test.mjs
node .\scripts\windows-selectlite-contract.test.mjs
node .\scripts\windows-ime-restore.test.mjs
node .\scripts\windows-right-ctrl-policy.test.mjs
node .\scripts\long-input-local-qwen-contract.test.mjs
node .\scripts\windows-startup-lifecycle-contract.test.mjs
node .\scripts\windows-package-msvc.test.mjs
npm --prefix openless-all\app run build

Failed

node .\scripts\windows-ui-config.test.mjs

Failure:

windows runtime should disable native chrome before the first show: pattern /#\[cfg\(target_os = windows\)\][\s\S]*?main\.set_decorations\(false\)/ not found

Gate decision

Keep #482 open. The CSS opaque-canvas contract is covered, but the Windows runtime native-chrome/decorations contract is not. This should not be hidden inside #490; it needs either a targeted fix or an explicit decision that native chrome is acceptable for the current beta, with screenshot evidence.

[Cooper-X-Oak]

This was generated by AI during triage.

Evidence update - native chrome contract now real-machine green

The earlier static gate was not strong enough. It only proved that the source called set_decorations(false), but a real Windows debug run still showed the native non-client chrome.

Reproduced red state

Before the targeted fix, a real OPENLESS_SHOW_MAIN_ON_START=1 debug launch found the main window with:

styleHex=0x14CF0000
hasCaption=true
hasThickFrame=true
hasSysMenu=true

The screenshot showed the bug clearly: Windows native titlebar on top plus the React WindowChrome titlebar below it, i.e. a double-titlebar / native white edge state.

Targeted fix

• Keep the shared Tauri config unchanged for macOS traffic lights.
• On Windows main-window setup, call disable_windows_main_native_chrome(&main) before first show.
• Pair Tauri decoration state with a direct Win32 non-client style strip:
  • remove WS_CAPTION
  • remove WS_THICKFRAME
  • remove WS_SYSMENU
  • remove min/max box styles
  • refresh with SWP_FRAMECHANGED
• Re-apply the strip on RunEvent::Ready, show_main_window, and after the React Windows maximize action so a later Tao/Tauri state transition cannot grow the native caption back.
• Keep the React Windows titlebar + explicit resize handles as the replacement chrome.

Validation passed

node .\scripts\windows-ui-config.test.mjs
node .\scripts\windows-main-opaque-canvas.test.mjs
npm run build
cargo build --manifest-path openless-all\app\src-tauri\Cargo.toml --bin openless

Real-machine smoke after the fix:

styleHex=0x14000000
hasCaption=false
hasThickFrame=false
hasSysMenu=false
screenshot=.artifacts/windows-beta/482/main-frameless-smoke.png

Gate decision: #482 is locally green for the Windows native chrome/decorations contract. This should become the second-round PR after #490 is merged, with #480 still kept out because its QA Esc/floating-window lifecycle red light is a separate third-round issue.

[Cooper-X-Oak]

Closing per author request. I am pausing involvement with this project for now.