WebView (Windows): fix startup flicker via --default-background-color - #26
Merged
Merged
Conversation
Plugins that gate the WebView's visibility on a first-paint handshake see a white flash on Windows because put_DefaultBackgroundColor is applied in setWebViewPreferences() — *after* the controller is created and may have already painted its default opaque-white frame. Pass the configured WinWebView2::backgroundColour through to the chromium renderer via --default-background-color in AdditionalBrowserArguments on the environment options, so the renderer process is launched with our colour already set. This mirrors the AppleWkWebView::drawsBackground = NO trick added in #24 and addresses the same flicker pattern on Windows that that PR fixed on macOS. The existing post-creation put_DefaultBackgroundColor call stays — it covers later paints (navigation, new contexts). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Plugins that gate webview visibility on a first-paint handshake see a white flash on first reveal on Windows. PR #24 fixed the equivalent flicker on macOS via WKWebView's `drawsBackground = NO` KVC trick; this PR fixes the Windows side.
The existing `put_DefaultBackgroundColor` call in `setWebViewPreferences()` runs after the controller is created. By that point the renderer process can already have painted its default opaque-white frame. This patch passes the configured `WinWebView2::backgroundColour` through to the chromium renderer at process-launch time via `--default-background-color` in `ICoreWebView2EnvironmentOptions::AdditionalBrowserArguments`, so the first paint already uses the host colour.
Why this works
`AdditionalBrowserArguments` is applied when WebView2 spawns its renderer process. The chromium `--default-background-color` switch is read at renderer init, before any web content is loaded, before any frame is painted. Tauri/wry use the same approach for the same reason.
The existing post-creation `put_DefaultBackgroundColor` call stays — it covers later paints (navigation between origins, new contexts, etc.) and isn't redundant.
Test plan
🤖 Generated with Claude Code