Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#5,673 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Ambito
desktop, operating-systems

Direzione di ricerca

Inizia dal percorso di visibilità di CoreWebView2Controller, incluso put_IsVisible(TRUE), e dalla riproduzione di wry WebViewBuilder/set_visible descritta qui. Riproduci il problema con HWND figli nascosti adiacenti, quindi confronta le modifiche alla visibilità con i trigger di ridisegno elencati. Il lavoro sarà completato quando il contenuto apparirà immediatamente dopo che il controllo diventa visibile, senza un'interazione non correlata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
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

Lingua principale
PowerShell
Stelle
526
Fork
67
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MicrosoftEdge/WebView2Feedback

Tutte le issue di MicrosoftEdge/WebView2Feedback

Issue simili

Altre issue su Desktop Dev

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.