[Problem/Bug]: Webview stays blank/stale after being made visible following creation while hidden — until an unrelated window interaction forces a repaint

What happened?

We host several CoreWebView2Controller instances as sibling child HWNDs inside one parent window (each acting as a "tab"), created with put_IsVisible(FALSE) and made visible later once the page has finished loading (CoreWebView2::NavigationCompleted / a wry PageLoadEvent::Finished equivalent).

After put_IsVisible(TRUE) is called, the control's own content is genuinely rendered (confirmed via visual inspection) but does not appear on screen — the region shows the parent window's background instead. This resolves itself automatically as soon as an unrelated interaction causes any repaint of the parent window (switching to a different already-visible tab and back, Alt-Tab, resizing).

We tried several application-side workarounds without success:

1. waiting for the page load "Finished" event before calling put_IsVisible(TRUE)
2. setting DefaultBackgroundColor to match our app's theme
3. forcing a resize (shrink by 1px, then restore) immediately after showing the control, which reliably triggers WM_SIZE

None of these reliably force the compositor to actually present the already-rendered content. Only an unrelated external repaint trigger resolves it.

This looks related to MicrosoftEdge/WebView2Feedback#1412 ("Flash when using Multiple WebViews in Tab Controls"), which was closed with labels bug / priority-low / tracked, but describes the same underlying "control removed from/reinserted into a container, unformatted hole appears" symptom for the deactivation/reactivation case.

Importance

----Please select----

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

151.0.4129.78

SDK Version

1.0.3405

Framework

Other

Operating System

Windows 11

OS Version

26200.9168

Repro steps

1. Create N sibling child HWND webviews inside a single parent window (e.g. via wry's WebViewBuilder targeting the same tao Window), each hidden with with_visible(false).
2. For a given webview, navigate it and wait for PageLoadEvent::Finished (content is confirmed rendered internally).
3. Call set_visible(true) on that webview.
4. Observe: the region where the webview should now show its content instead shows the parent window's own background — the webview is logically visible but its content isn't presented.
5. Switch focus/visibility to a different, already-visible sibling webview and back (or Alt-Tab away and back, or resize the window).
6. The originally-stuck webview now shows its content correctly, with no further action.

Expected: content should be presented immediately after step 3.
Actual: content is only presented after an unrelated repaint trigger in step 5.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

Start with the CoreWebView2Controller visibility path, including put_IsVisible(TRUE), and the wry WebViewBuilder/set_visible repro described here. Reproduce with sibling hidden child HWNDs, then compare visibility changes with the listed repaint triggers. Done would mean content appears immediately after the control becomes visible without an unrelated interaction.