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

Activity

1. Cooper-X-Oak commented on May 18, 2026

   

   Cooper-X-Oak

   on May 18, 2026

   ContributorAuthor

   More actions

   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.
2. Cooper-X-Oak commented on May 18, 2026

   

   Cooper-X-Oak

   on May 18, 2026

   ContributorAuthor

   More actions

   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.
3. Cooper-X-Oak commented on May 18, 2026

   

   Cooper-X-Oak

   on May 18, 2026

   ContributorAuthor

   More actions

   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.
4. Cooper-X-Oak commented on May 19, 2026

   

   Cooper-X-Oak

   on May 19, 2026

   ContributorAuthor

   More actions

   Closing per author request. I am pausing involvement with this project for now.
5. Cooper-X-Oak

   closed this as completedon May 19, 2026