[bug] setTheme resolves but no longer repaints the standard macOS title bar on macOS 26 (raw tao 0.35.3 + wry 0.55.1 works)

[acxtodd]

Describe the bug

On macOS 26.5.1 (25F80), Window.setTheme('dark'|'light') (and app.setTheme) resolves successfully but the standard title bar never repaints in a Tauri 2.11.2 app — while the identical underlying call works correctly in a raw tao 0.35.3 + wry 0.55.1 program on the same machine.

Evidence gathered before filing:

• The IPC resolves (no capability error; core:window:allow-set-theme granted).
• The appearance override IS applied at the AppKit level: inside the webview, matchMedia('(prefers-color-scheme: dark)') flips in lockstep with setTheme — so NSApplication.setAppearance took effect and reached the view hierarchy. Only the window-server-drawn standard title bar stays in the OS appearance.
• window.theme() is not usable as verification: tao returns the optimistically cached shared_state.current_theme (set by set_theme itself), and the KVO handler suppresses ThemeChanged when the cache already matches.
• Not the fix(macos): run app.set_theme on main thread #13443 class: in 2.11.2 the window set_theme is dispatched through the event-loop proxy (tauri-runtime-wry lib.rs:2528 → :3675) and runs on the main thread; app.setTheme behaves identically to window.setTheme here (both resolve, neither repaints the bar).
• Single-variable bisection (all on the same machine, human-observed):

Configuration	Standard title bar follows setTheme?
tao 0.35.3, bare binary	✅ flips
tao + embedded Info.plist	✅ flips
tao + Info.plist + wry 0.55.1 WKWebView attached (goes through wry's setTitlebarSeparatorStyle path)	✅ flips
minimal Tauri 2.11.2 (default config, static HTML, no plugins, withGlobalTauri)	❌ never flips (setTheme resolves on-screen)

So the regression surface is bracketed inside tauri/tauri-runtime-wry window/event-loop wiring, between raw tao+wry and a default Tauri app.

Reproduction

Minimal Tauri app (fails — bar never flips; src/main.rs is just tauri::Builder::default().run(tauri::generate_context!())):

tauri.conf.json:

{
  "productName": "tauri-min", "version": "0.1.0", "identifier": "com.diag.taurimin",
  "build": { "frontendDist": "./dist" },
  "app": { "withGlobalTauri": true, "windows": [ { "title": "TAURI MIN", "width": 700, "height": 400 } ] },
  "bundle": { "active": false }
}

capability: { "identifier": "default", "windows": ["main"], "permissions": ["core:default", "core:window:allow-set-theme"] }

dist/index.html:

<script>
  const w = window.__TAURI__.window.getCurrentWindow();
  let themes = ['dark','light','dark','light','dark','light','dark','light'], i = 0;
  const tick = async () => {
    if (i >= themes.length) return;
    const t = themes[i++];
    try { await w.setTheme(t); document.body.textContent = 'setTheme ' + t + ' OK (' + i + '/8)'; }
    catch (e) { document.body.textContent = 'setTheme FAILED: ' + e; }
    setTimeout(tick, 4000);
  };
  setTimeout(tick, 4000);
</script>

Control program (works — bar flips every cycle; same behavior with an Info.plist embedded via -sectcreate and with a wry 0.55.1 webview attached via WebViewBuilder::new().with_url("about:blank").build(&window)):

use std::{thread, time::Duration};
use tao::{event::{Event, WindowEvent}, event_loop::{ControlFlow, EventLoopBuilder}, window::{Theme, WindowBuilder}};

fn main() {
  let event_loop = EventLoopBuilder::<Theme>::with_user_event().build();
  let window = WindowBuilder::new().with_title("TAO THEME ISOLATION").build(&event_loop).unwrap();
  let proxy = event_loop.create_proxy();
  thread::spawn(move || {
    let mut next = Theme::Dark;
    for _ in 0..8 {
      thread::sleep(Duration::from_secs(4));
      let _ = proxy.send_event(next);
      next = if matches!(next, Theme::Dark) { Theme::Light } else { Theme::Dark };
    }
    thread::sleep(Duration::from_secs(4));
    std::process::exit(0);
  });
  event_loop.run(move |event, _, control_flow| {
    *control_flow = ControlFlow::Wait;
    match event {
      Event::UserEvent(theme) => { window.set_theme(Some(theme)); println!("set_theme({theme:?})"); }
      Event::WindowEvent { event: WindowEvent::CloseRequested, .. } => *control_flow = ControlFlow::Exit,
      _ => (),
    }
  });
}

Expected behavior

The standard macOS title bar follows setTheme, as it does in the raw tao 0.35.3 + wry 0.55.1 control on the same OS.

Full tauri info

• macOS 26.5.1 (25F80), Apple Silicon
• tauri 2.11.2 / tauri-runtime-wry 2.11.2 / tao 0.35.3 / wry 0.55.1 / @tauri-apps/api 2.11.0 / CLI 2.11.2

(Happy to run further bisection builds — the two repro programs above bracket the defect.)

[acxtodd]

Additional datum tightening the version bracket, same machine (macOS 26.5.1):

• A Tauri 2.10.3 production app (tauri-runtime-wry 2.10.1 / tao 0.34.6 / wry 0.54.3, no theme config, no setTheme calls) renders its standard title bar correctly following the OS appearance (dark bar under dark OS).
• The minimal Tauri 2.11.2 repro from the report renders a light title bar even when the OS is in dark mode AND the active setTheme('dark') override is in effect — i.e., the 2.11-generation chrome appears stuck light, not merely deaf to runtime repaints.

So this looks like a regression between the 2.10.x and 2.11.x generations of tauri/tauri-runtime-wry (tao itself is exonerated at 0.35.3 — the raw-tao control in the report flips correctly). I checked tauri-runtime-wry 2.11.2→2.11.4: no theme-related changes. Happy to build the minimal repro against intermediate versions if a finer bisection helps.

[acxtodd]

Mechanism identified (supersedes part of my analysis above): on macOS 26, the standard title bar over a Tauri webview window renders according to the web document's CSS color-scheme, not the app's NSApp.setAppearance state.

Verified with the same minimal 2.11.2 repro, replacing all Tauri calls with pure CSS: toggling color-scheme: dark (+ dark background) on <html> every 4s — the standard title bar follows it perfectly, both directions, zero native calls. This also explains the earlier version-bracket observation: the 2.10.3 production app I referenced declares color-scheme on <html> (via next-themes), so its bar was tracking the page, not the OS.

Remaining anomalies for maintainers:

1. window.setTheme/app.setTheme resolve and change the app's effectiveAppearance (webview matchMedia flips) but never affect the chrome of a Tauri window on macOS 26 — while the same tao set_theme call DOES flip the chrome in a raw tao 0.35.3 window, and even in a raw tao + wry 0.55.1 window with an undeclared about:blank page. Something about the Tauri window/webview wiring makes the chrome ignore the app appearance and defer exclusively to the page's color-scheme (defaulting light when undeclared).
2. window.theme() cannot detect any of this (tao returns its optimistic cache).

Workaround for anyone hitting this: declare color-scheme on your document root and keep it in sync with your app theme — the title bar follows it on macOS 26 regardless of setTheme.

[acxtodd]

Final mechanism isolation (supersedes my color-scheme comment above): a three-phase on-device test with the same minimal repro — (A) color-scheme: dark alone, (B) dark html background alone, (C) both — shows the macOS 26 standard title bar follows the document's background color: phase B alone flips the chrome; phase A alone does not. (My earlier color-scheme attribution was a confound — the original cycler changed both together.)

Corrected workaround: keep the html element's background in sync with your app theme (e.g. :root:has(...) { background: <dark>; }). color-scheme is still worth declaring for UA scrollbars/native controls, but it does not drive the chrome. Verified in a production app: with the theme-synced document background, the title bar now follows the in-app theme toggle correctly on macOS 26.5.1 / Tauri 2.11.2.

The original anomalies stand for maintainers: window.setTheme/app.setTheme resolve and change the app's effectiveAppearance but never repaint the chrome of a Tauri window (while flipping the chrome fine in raw tao / tao+wry windows), and window.theme() reflects tao's optimistic cache.

[AmanxUpadhyay]

Could you assign this issue to me? I’d love to help. I recently delivered a PaaS using Tauri, and it was a lifesaver.