WebView (Windows): suppress background flash on creation and hide/show - #28
Merged
Merged
Conversation
Two complementary fixes that together close the white-flash windows we've been chasing in the embedded webview: 1. Switch the renderer's default background colour from a chromium CLI switch (--default-background-color via AdditionalBrowserArguments) to the WEBVIEW2_DEFAULT_BACKGROUND_COLOR environment variable. Same goal, but works through the Microsoft-documented runtime path so it's less likely to drift across chromium versions. 2. Stamp the WebView2 host HWND's class background brush with the configured background colour. WebView2's class defaults to a white brush, which the OS paints into the HWND's initial pixel buffer at creation and on some restore paths -- visible as a flash before the renderer composites its first frame. The deeper descendant HWNDs (Chrome_WidgetWin_1, Intermediate D3D Window, Chrome_RenderWidgetHostHWND) are owned by the WebView2 renderer process and SetClassLongPtrW returns ERROR_ACCESS_DENIED for them, so we only stamp the direct browser-host child we associated above. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jakepenn
force-pushed
the
webview-win-suppress-bg-flash
branch
from
May 25, 2026 18:19
372bd2f to
a8b2868
Compare
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
Two complementary fixes that close the white-flash windows the embedded WebView2 exposes around hide/show and initial paint:
WEBVIEW2_DEFAULT_BACKGROUND_COLORenv var — replaces the chromium--default-background-colorCLI switch (set viaAdditionalBrowserArgumentsfrom WebView (Windows): fix startup flicker via --default-background-color #26). Same goal, but works through the Microsoft-documented runtime path, so it's less likely to drift across chromium versions.Chrome_WidgetWin_1,Intermediate D3D Window,Chrome_RenderWidgetHostHWND) live in the renderer process, andSetClassLongPtrWreturnsERROR_ACCESS_DENIEDfor them. Stamping the one HWND we own covers the common case.Used together with the consumer-side work in
minimal_core(translation-based hide for the WebView2, noput_IsVisibleround-trips), these two fixes eliminate the white flashes on cold boot, native overlay open, and native overlay dismiss.Test plan
🤖 Generated with Claude Code