[bug] White gaps appear on window resize or maximize in macOS app (SvelteKit + Tauri)

[atillayurtseven]

Describe the bug

When running a SvelteKit app inside a macOS Tauri window with a black background (background-color: #000 or similar) and height: 100%, width: 100%, white gaps appear on the right and bottom edges during resizing or maximizing the window.

The layout realigns correctly only after the resize event finishes, not during the resize.

Reproduction

1. Create a new SvelteKit + Tauri app (macOS).
2. Set the body or main container to:
   html, body { background-color: #000; width: 100%; height: 100%; margin: 0; }
3. Resize or maximize the window.

Expected behavior

The background should remain fully black at all times, no white margins should appear while resizing or after maximizing the window. All components must aligned correctly even during the resize.

Full tauri info output

[✔] Environment
    - OS: Mac OS 26.0.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ Xcode: 26.0.1
    ✔ rustc: 1.90.0 (1159e78c4 2025-09-14)
    ✔ cargo: 1.90.0 (840b83a10 2025-07-30)
    ✔ rustup: 1.28.2 (e4f3ad6f8 2025-04-28)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (overridden by environment variable RUSTUP_TOOLCHAIN)
    - node: 22.16.0
    - pnpm: 10.13.1
    - yarn: 1.22.22
    - npm: 11.6.0

[-] Packages
    - tauri 🦀: 2.8.5
    - tauri-build 🦀: 2.4.1
    - wry 🦀: 0.53.4
    - tao 🦀: 0.34.3
    - tauri-cli 🦀: 2.8.4
    - @tauri-apps/api : 2.8.0
    - @tauri-apps/cli : 2.8.4

[-] Plugins
    - tauri-plugin-log 🦀: 2.7.0
    - @tauri-apps/plugin-log : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../public
    - devUrl: http://localhost:5173/
    - framework: Svelte
    - bundler: Vite

Stack trace

Additional context

Setting the background to black in multiple places (including app.html) does not prevent the white area.

[lucasfernog]

probably the same bug as #13898

[JJJ]

I can reproduce this on current Tauri with a deliberately minimal, opaque, separate window, so this does not appear to require Svelte/React, application layout complexity, transparency, vibrancy, or CSS backdrop filters.

Environment:

macOS 27.0 arm64
Tauri 2.11.5
tauri-build 2.6.3
Wry 0.55.1
Tao 0.35.3
@tauri-apps/api 2.11.1
@tauri-apps/cli 2.11.4

The isolated test creates a normal decorated, resizable WebviewWindow with transparent: false. Its local HTML contains no framework—only:

html, body {
  width: 100%;
  height: 100%;
  margin: 0;
  background: #081426;
}

.frame { position: fixed; inset: 0; background: #173c70; }
.right-edge { position: fixed; inset-block: 0; inset-inline-end: 0; width: 24px; background: red; }
.bottom-edge { position: fixed; inset-inline: 0; inset-block-end: 0; height: 24px; background: yellow; }

During a rapid live resize, the fixed right/bottom markers visibly trail or flutter behind the native window edge in the same manner as the full application. Toggling root overflow between hidden and visible did not eliminate it.

Additional things tested without materially improving the live resize:

• Explicitly forcing the WKWebView and its native superview frames to their parents' bounds on every WindowEvent::Resized.
• NSWindow.preservesContentDuringLiveResize = false.
• NSViewLayerContentsRedrawPolicy::DuringViewResize.
• Painting a matching native/window underlay (this can mask the exposed color, but the web content still arrives late).

This looks like the native window/view frames advance correctly while WKWebView's remotely composited page surface is presented a frame or more later.

There is a very close independent report from a JUCE WebBrowserComponent test, including right/bottom gaps and failure of native background painting to solve the underlying lag: https://forum.juce.com/t/webview-resize-jitter-bug/68515

This is also reproducible without DevTools, so it seems distinct from tauri-apps/wry#297. It does look related to #13898, but that issue emphasizes the native title-bar zoom animation whereas this reproduction occurs during ordinary pointer-driven live resize.

Would the Tauri/Wry maintainers prefer a lower-level Wry issue or a standalone reproduction repository for this case?

[FabianLars]

Assuming that the window background color (via tauri config or tauri api, not talking about html/css) doesn't have the same issue i don't think there's much we can do (you already said this prevents the color flash so...).
webviews / web engines (most browsers have similar issues), are simply a bit slower at resizing. Can't remember webkit but chromium for example also has vastly different behavior with hardware acceleration enabled vs disabled. If you disable it, resizing becomes much smoother but then you don't have hardware accel 🙃

tldr: i think this is a wontfix for "normal" resizing

[atillayurtseven]

I gave everything to Codex. Told it to find the exact problem. Turned out Tao was the real problem. Fixed by Codex. Maybe a dirty one but fixed.

[atillayurtseven]

Assuming that the window background color (via tauri config or tauri api, not talking about html/css) doesn't have the same issue i don't think there's much we can do (you already said this prevents the color flash so...). webviews / web engines (most browsers have similar issues), are simply a bit slower at resizing. Can't remember webkit but chromium for example also has vastly different behavior with hardware acceleration enabled vs disabled. If you disable it, resizing becomes much smoother but then you don't have hardware accel 🙃

tldr: i think this is a wontfix for "normal" resizing

Here's how codex fixed. I believe you can find a better fix.

Cause: Tao calls NSWindow.zoom() synchronously while holding its shared window state. AppKit animates the outer window, but WKWebView does not receive every intermediate resize frame, causing background flashes and choppy content updates.

Fix: Intercept windowShouldZoom, cancel the default zoom, release the shared-state lock, then animate the target frame asynchronously with NSAnimationContext and window.animator().setFrame(). This lets WKWebView’s autoresizing follow every animation frame.

[FabianLars]

That's for #13898 and is also contributed here tauri-apps/tao#1207 but it does not help with the general resizing.

[JJJ]

I followed this all the way down through Tauri → Tao → Wry and into WebKit. The pointer-driven live-resize case is a WebKit UI-process presentation bug, rather than the Tao title-bar zoom issue discussed in #13898.

Upstream tracking and proposed fix:

• WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=323132
• Draft WebKit PR: [macOS] WKWebView content lags behind its bounds during live window resize WebKit/WebKit#72971

During live resize, AppKit advances the WKWebView bounds synchronously while the last remotely committed page surface remains at its previous size. The proposed fix keeps that committed surface covering the current view with presentation-only Core Animation overrides until WebContent commits the final geometry.

For an end-to-end check, I launched my real Tauri app (Pasted) with unchanged application, Tauri, Tao, and Wry code - and recorded the same automated fast upper-left resize twice: once with Apple’s stock WebKit and once with the locally built patched WebKit. I verified the loaded image in each live process with vmmap before recording. The stock run reproduces the lag; the patched run keeps the content attached to the moving window.

The attached before/after movies use a black privacy backdrop and Pasted’s Settings screen with its sidebar collapsed, and the difference frame-by-frame is quite clear:

Stock WebKit: https://github.com/user-attachments/assets/144de983-4924-40d1-806d-599e1e1bb8bd

Patched WebKit: https://github.com/user-attachments/assets/a1917a00-a03d-48a6-a0a7-08f47d6272bd

i think this is a wontfix

For Tauri, I think I agree. 😂