B-R22U-macos-window-vibrancy-is-inert-until-the-webview-background

State: closed/abandoned

Closed. The owner decided against macOSPrivateApi, so the work below will not be done. D-0040 records the decision and its consequences.

The NSVisualEffectView is attached to the fitness window (platform_core::run_with / RunOptions / VibrancyMaterial::Sidebar) but sits under the WKWebView, which paints an opaque background over it. Nothing is visible, and nothing will be.

Making it visible would need four changes plus a Cargo feature:

appConfig.shell.chrome.material true for fitness in products/fitness/nuxt.config.ts (the default is false in SHELL_CHROME_DEFAULTS)
body’s --d-bg-base ground cleared where the material regions sit (app-frame/app/assets/shell.css, opaque for all 28 products)
"transparent": true on the fitness window
"macOSPrivateApi": true on the fitness window
the macos-private-api feature on product-fitness’s tauri dependency, which currently takes tauri = { workspace = true } with no local features. apps/pumice/src-tauri/Cargo.toml already sets it.

The last two are what closes the item. macOSPrivateApi bars App Store distribution, and the fitness product keeps that route. transparent is also window-wide, so dialogs, popovers and the command palette would have to re-opaque themselves.

The first two do not stand on their own. Turning the chrome material gate on while the ground stays opaque paints a flat translucent tint over an opaque surface — a washed-out sidebar with no blur behind it, which is worse than the flat ground it replaces.

The Cargo-workspace question this item raised is answered, and the answer is its own item: apps/pumice/src-tauri and solutions/determined/products/*/src-tauri are members of the same root workspace, and pumice’s macos-private-api feature does unify onto tauri in a workspace-wide build. See B-QZ3T-pumice-macos-private-api-unifies-across-the-root-cargo-workspace.

← Back to Backlog