Environment
- electrobun 1.18.1 (also checked 1.18.4-beta commit history — no related change)
- Windows 11,
renderer: "native" (WebView2), evergreen runtime
- Dark app (opaque dark CSS background)
Symptom
During live window resize, the newly exposed regions flash white before Chromium catches up. With a dark UI this is very visible. This is independent of the initial client-size bug (#462) — it happens on every resize after the layout is correct.
What I ruled out (color-probe test)
I painted each host-side layer a different primary color and resized:
| Layer |
How |
Result |
| WebView2 default background |
WEBVIEW2_DEFAULT_BACKGROUND_COLOR=FFFF0000 set in-process via SetEnvironmentVariableW before any controller is created |
bands stay white |
Main window (BasicWindowClass) |
SetClassLongPtrW(GCLP_HBRBACKGROUND) green brush |
bands stay white |
Container (ContainerViewClass, registered with hbrBackground = NULL) |
same, blue brush |
bands stay white |
None of the three colors ever show, so the white is painted inside WebView2's own child windows (owned by the msedgewebview2.exe processes) — not fixable from the host app.
Root cause / request
nativeWrapper.cpp always creates webviews with windowed hosting (CreateCoreWebView2Controller). White resize bands are a long-standing artifact of WebView2 windowed hosting. The known cure is visual hosting via CreateCoreWebView2CompositionController (DComp) — the file already includes dcomp headers and a comment ("When DComp is active, use CreateCoreWebView2CompositionController"), but the composition path is never taken for regular webviews.
Would you consider composition (DComp) hosting for WebView2 on Windows (even as an opt-in), so resize doesn't flash white?
Happy to test builds on Windows.
Environment
renderer: "native"(WebView2), evergreen runtimeSymptom
During live window resize, the newly exposed regions flash white before Chromium catches up. With a dark UI this is very visible. This is independent of the initial client-size bug (#462) — it happens on every resize after the layout is correct.
What I ruled out (color-probe test)
I painted each host-side layer a different primary color and resized:
WEBVIEW2_DEFAULT_BACKGROUND_COLOR=FFFF0000set in-process viaSetEnvironmentVariableWbefore any controller is createdBasicWindowClass)SetClassLongPtrW(GCLP_HBRBACKGROUND)green brushContainerViewClass, registered withhbrBackground = NULL)None of the three colors ever show, so the white is painted inside WebView2's own child windows (owned by the
msedgewebview2.exeprocesses) — not fixable from the host app.Root cause / request
nativeWrapper.cppalways creates webviews with windowed hosting (CreateCoreWebView2Controller). White resize bands are a long-standing artifact of WebView2 windowed hosting. The known cure is visual hosting viaCreateCoreWebView2CompositionController(DComp) — the file already includes dcomp headers and a comment ("When DComp is active, use CreateCoreWebView2CompositionController"), but the composition path is never taken for regular webviews.Would you consider composition (DComp) hosting for WebView2 on Windows (even as an opt-in), so resize doesn't flash white?
Happy to test builds on Windows.