[sheiksyedm]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue details

On WPF, awaiting BlazorWebView.DisposeAsync() can hang when a Razor component or scoped service awaits JavaScript interop during its asynchronous disposal.

For example, a scoped service implementing IAsyncDisposable can await IJSRuntime.InvokeVoidAsync during cleanup. The same problem affects components that perform asynchronous JS cleanup, such as disposing an IJSObjectReference module.

The disposal-time JS invocation is silently dropped rather than completed or faulted. Consequently, the component or service cannot finish disposal, and the owning BlazorWebView.DisposeAsync() remains incomplete. Catching JSDisconnectedException does not help because no such exception is raised by this path.

The reported real-world scenario involves closing a WPF dialog containing a DevExpress Blazor component whose scoped service releases JS modules during disposal.

Root cause

WPF's BlazorWebView.DisposeAsync() calls _webviewManager.MarkAsDisposing() before disposing the page through the WebView manager.

That flag causes WebView2WebViewManager.SendMessage() to return without sending messages. However, page disposal still needs to dispose the Razor renderer and scoped services, and their cleanup code can await JS interop.

This ordering blocks the JS invocation that disposal itself is waiting to complete:

1. The control marks the manager as disposing.
2. Page disposal invokes component or scoped-service cleanup.
3. Cleanup awaits a JS interop call.
4. SendMessage() drops the outgoing invocation because the manager is already marked as disposing.
5. Cleanup cannot finish, so control disposal cannot finish either.

Additionally, the existing ConfigureAwait(false) can move native WebView cleanup off the WPF UI thread when manager disposal completes asynchronously.

Fix description

• Keep JS messaging available while awaiting WebView manager disposal, allowing component and scoped-service JS cleanup to complete.
• Call MarkAsDisposing() after manager/page disposal completes and before disposing the native WebView.
• Use ConfigureAwait(true) to preserve the WPF UI context for native WebView disposal.
• Update the shared manager's documentation to describe the required disposal order.

The existing late-message guards in SendMessage() remain in place. The control's _isDisposed guard is also retained.

The functional change is limited to the WPF BlazorWebView implementation. No MAUI handler behavior is changed.

Why no automated regression test is included

No existing automated tests targeting the WPF BlazorWebView implementation were found in this repository. The existing BlazorWebView unit and device test projects target the MAUI implementation; the WPF application is a sample rather than an automated test suite.

A representative regression test would require a WPF host running on an STA/UI dispatcher with a real WebView2 instance and JS interop. This PR does not introduce a new WPF test project or test infrastructure. Adding a MAUI test would not cover the affected WPF disposal path.

Instead, the fix was verified using a separate executable WPF reproduction harness. That harness and the MAUI Sandbox comparison changes are not included in this PR.

Verification

Verified locally on Windows 11 with a real WebView2 runtime, using both the reported package version (10.0.110) and source-built WPF libraries.

The WPF reproduction initializes Blazor, instantiates the scoped service, and successfully completes a JS preflight call before disposing the control on the WPF UI thread. A bounded 10-second observation distinguishes completed disposal from the reported hang.

Scenario	Before fix	After fix
Scoped service awaits JS during disposal	Service entered disposal, but its JS call and control disposal remained incomplete after 10 seconds	JS call, service disposal, and control disposal completed
Razor component awaits JS during disposal	Component entered disposal, but its JS call and control disposal remained incomplete after 10 seconds	JS call, component disposal, and control disposal completed
Scoped service disposes without calling JS	Disposal completed	Disposal completed

All three scenarios completed successfully in three repeated runs each against the patched source-built WPF library. Subsequent runs of the local verification script also passed.

Issues Fixed

Fixes #39471

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 39497

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 39497"

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🔵 Needs a closer look

The native WPF/WebView2 lifecycle change needs completed CI and human confirmation of the reported runtime verification.

No open issues 🎉

What changed in this PR

Fixes the WPF BlazorWebView disposal hang described in #39471 by keeping JavaScript interop available during component and scoped-service cleanup.

Changes:

• Delays message shutdown until manager disposal completes.
• Preserves the WPF UI context for native WebView disposal.
• Updates shared documentation to describe the disposal order; MAUI handler behavior is unchanged.

File	Description
src/​BlazorWebView/​src/​Wpf/​BlazorWebView.cs	Reorders disposal and preserves the UI context.
src/​BlazorWebView/​src/​SharedSource/​WebView2WebViewManager.cs	Updates disposal-order documentation only.

_{Review effort: Balanced}