feat(desktop): add configurable Windows Acrylic backdrop - #8643
feat(desktop): add configurable Windows Acrylic backdrop#8643mathofdynamic wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
|
|
||
| .electron-windows { | ||
| --desktop-window-right-resize-inset: 6px; | ||
| --desktop-window-canvas: color-mix(in srgb, var(--background) var(--glass-opacity), transparent); |
There was a problem hiding this comment.
🟡 Medium src/index.css:2021
When setBackgroundMaterial("acrylic") fails, the renderer keeps data-desktop-backdrop="on", so --desktop-window-canvas remains the glass-opacity color-mix instead of the solid --background fallback. The main surface is therefore blended with the native fallback color, and changing Glass opacity still affects an opaque window; update the backdrop state to off when Acrylic setup fails.
🤖 Copy this AI Prompt to have your agent fix this:
In file @apps/web/src/index.css around line 2021:
When `setBackgroundMaterial("acrylic")` fails, the renderer keeps `data-desktop-backdrop="on"`, so `--desktop-window-canvas` remains the glass-opacity `color-mix` instead of the solid `--background` fallback. The main surface is therefore blended with the native fallback color, and changing Glass opacity still affects an opaque window; update the backdrop state to `off` when Acrylic setup fails.
| html.electron-windows [data-app-sidebar], | ||
| html.electron-windows [data-slot="sidebar-inner"] { | ||
| background-color: var(--desktop-window-sidebar) !important; | ||
| } |
There was a problem hiding this comment.
🟡 Medium src/index.css:2051
With Acrylic enabled, [data-app-sidebar] is tinted using the root --sidebar color, so its local light/dark or theme palette is ignored. --desktop-window-sidebar is resolved before the sidebar's --sidebar override is inherited; define the mix on [data-app-sidebar] so it uses the local token.
}
+
+html.electron-windows [data-app-sidebar] {
+ --desktop-window-sidebar: color-mix(in srgb, var(--sidebar) var(--glass-opacity), transparent);
+}🤖 Copy this AI Prompt to have your agent fix this:
In file @apps/web/src/index.css around line 2051:
With Acrylic enabled, `[data-app-sidebar]` is tinted using the root `--sidebar` color, so its local light/dark or theme palette is ignored. `--desktop-window-sidebar` is resolved before the sidebar's `--sidebar` override is inherited; define the mix on `[data-app-sidebar]` so it uses the local token.
There was a problem hiding this comment.
One finding on the new Windows Acrylic renderer CSS: the global !important overrides target the bg-background / bg-sidebar Tailwind utilities rather than the app-shell surfaces that own the window canvas, so they also repaint every form control and floating surface that happens to use those utilities.
Posted via Macroscope — UI Consistency
| html.electron-windows .bg-background, | ||
| html.electron-windows [data-slot="sidebar-inset"] { | ||
| background-color: var(--desktop-window-canvas) !important; | ||
| } | ||
|
|
||
| html.electron-windows .bg-sidebar, | ||
| html.electron-windows [data-app-sidebar], | ||
| html.electron-windows [data-slot="sidebar-inner"] { | ||
| background-color: var(--desktop-window-sidebar) !important; | ||
| } |
There was a problem hiding this comment.
These rules key off the bg-background / bg-sidebar utility classes, not the window-canvas surfaces, so on Windows they repaint far more than the app shell:
bg-backgroundis a base class onInput,Textarea,Selecttrigger,InputGroup,Combobox,NumberField,Checkbox,RadioGroup,Toggle, outlineBadge, and theSwitch/ menu-checkbox thumbs. All of them becomecolor-mix(--background var(--glass-opacity), transparent).- Because the declaration is
!importantand unlayered, it also beats the state variants declared on those same elements (dark:bg-input/32,dark:not-data-checked:bg-input/32,dark:data-pressed:bg-input,has-autofill:bg-foreground/4, and call-sitehover:bg-accent, e.g.KeybindingsSettings.tsx:852). Dark-mode inputs lose their--inputsurface, autofill highlighting disappears, and pressed/hover feedback on toggles and shortcut rows stops rendering. --desktop-window-canvasis computed onhtml, so itsvar(--background)is substituted with the root value. Controls inside[data-app-sidebar], which deliberately redefines--background/--sidebarlocally (index.css:1500,1836), now resolve the root palette instead of the sidebar palette..bg-sidebaradditionally matches the portaled mobile sidebarSheet(ui/sidebar.tsx:239), which floats over content rather than over the desktop, so it turns translucent against the app instead of the Acrylic material.
The attribute selectors already listed here ([data-slot="sidebar-inset"], [data-app-sidebar], [data-slot="sidebar-inner"]) are the real canvas owners. Suggest dropping the .bg-background / .bg-sidebar utility branches and giving the remaining full-bleed canvas call sites an explicit opt-in — e.g. an @utility surface-canvas backed by --desktop-window-canvas applied at the shell/route containers — so control primitives keep their own surface ownership. (Multi-file change, so no inline suggestion.)
Posted via Macroscope — UI Consistency
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5378598. Configure here.
| window.setBackgroundColor(getInitialWindowBackgroundColor(shouldUseDarkColors)); | ||
| } else { | ||
| yield* applyWindowsBackdrop(window, platform, shouldUseDarkColors, desktopBackdropEnabled); | ||
| } |
There was a problem hiding this comment.
Acrylic applied to every window
Medium Severity
syncAppearance walks every BrowserWindow from getAllWindows() and, for any window missing from the Acrylic WeakSets, calls applyWindowsBackdrop. That sets acrylic and a fully transparent backgroundColor on auxiliary windows such as undocked DevTools or preview popups whenever the theme changes or any client setting is saved.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 5378598. Configure here.
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This PR introduces Windows Acrylic as a new default and wires it through Electron window creation, persisted settings, live synchronization, and broad renderer surface styling. Its cross-cutting production impact and unresolved fallback, theming, UI-scope, and auxiliary-window concerns warrant human review. Not approved because:
Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more. |
1 participant
What changed
Windows desktop users currently have no setting for the native desktop blur shown by applications such as Windows Terminal. T3 Code's existing Glass opacity setting only controls renderer surfaces and cannot blur the desktop behind the Electron window.
This PR:
Validation
@t3tools/desktoptypecheck passed.@t3tools/webtypecheck passed.git diff --checkpassed.Scope
This is intentionally limited to the Windows desktop surface. The setting defaults on and uses the existing Glass opacity control to determine how much of the native backdrop is visible through app surfaces.
Generated with Codex (GPT-5.6) in T3 Code.
Note
Medium Risk
Changes Electron window creation and global Windows renderer styling; failures are mitigated with solid-background fallback, but Acrylic/transparent windows can still affect readability or GPU behavior on some systems.
Overview
Adds a persisted
desktopBackdropEnabledclient setting (default on) and wires it through contracts, settings UI, and IPC so Windows desktop users can toggle native Acrylic blur behind the app.On win32, Electron windows (main and WSL connecting splash) now use
getWindowBackdropOptions/applyWindowsBackdrop—transparent background, acrylic material when enabled, and a solid fallback if material APIs fail.setClientSettingstriggerssyncAppearanceso toggles apply without restart.The renderer exposes Desktop background blur only on Windows Electron, updates glass-opacity copy, syncs
data-desktop-backdropon the document root, and adjustsindex.cssso window chrome stays translucent and main/sidebar surfaces respect glass opacity. Settings search gains a windowsOnly filter. User docs describe the feature.Reviewed by Cursor Bugbot for commit 5378598. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Add configurable Windows Acrylic backdrop to desktop client
desktopBackdropEnabledtoClientSettingsschema, defaulting totrue.DesktopWindow.tsusing Windows-specific background materials and transparent colors for both main and splash windows.data-desktop-backdropwhen enabled.setClientSettingsIPC handler now callsdesktopWindow.syncAppearanceafter saving settings, andapplyWindowsBackdropfalls back to a solid background on failure.📊 Macroscope summarized 5378598. 9 files reviewed, 2 issues evaluated, 0 issues filtered, 2 comments posted
🗂️ Filtered Issues