WebViewJSRuntime should throw JSDisconnectedException when PageContext is disposed (parity with RemoteJSRuntime)

[mattleibow]

Description

When a BlazorWebView page reloads (e.g., location.reload(), Android app foregrounded after being backgrounded), the old PageContext is disposed via WebViewManager.AttachToPageAsync(). During disposal, components implementing IAsyncDisposable may invoke JS interop on IJSObjectReference — following Microsoft's recommended cleanup pattern.

These JS calls go through WebViewJSRuntime.BeginInvokeJS() → IpcSender → the reloaded page's JS context, where the old JS object IDs no longer exist. This produces an unhandled JSException: JS object instance with ID X does not exist (has it been disposed?).

In Blazor Server, RemoteJSRuntime handles this correctly by throwing JSDisconnectedException when the circuit is disposed (#32901). WebViewJSRuntime has no equivalent guard.

Reproduction

https://github.com/mattleibow/MauiBlazorReloadIssue

1. Run the MAUI Blazor Hybrid app on Windows or Android
2. Navigate to the Weather page (implements IAsyncDisposable with IJSObjectReference)
3. Click "Reload Page Now"
4. Unhandled JSException occurs

The Counter page (sync IDisposable, no JS in dispose) survives reload for comparison.

Proposed Fix

1. Add an IsDisposed / IsDisconnected flag to PageContext
2. Set it at the start of PageContext.DisposeAsync() (before Renderer.DisposeAsync())
3. In WebViewJSRuntime.BeginInvokeJS(), check the flag and throw JSDisconnectedException — matching RemoteJSRuntime behavior
4. JSObjectReference.DisposeAsync() already catches JSDisconnectedException on main (Change IJSObjectReference.Dispose specifically so that it deals with catching and discarding JSDisconnectedException internally #49418)

Additionally, guard IpcSender and IpcReceiver against disposed PageContext to prevent corruption of the new page state.

Affected files

• src/Components/WebView/WebView/src/PageContext.cs — add disposed flag
• src/Components/WebView/WebView/src/Services/WebViewJSRuntime.cs — throw JSDisconnectedException
• src/Components/WebView/WebView/src/IpcSender.cs — guard against disposed context
• src/Components/WebView/WebView/src/IpcReceiver.cs — ignore messages for disposed context

Related

• Page reload in Maui Hybrid Blazor app causes unhandled exception maui#31942 — original bug report (open since Nov 2023)
• Change IJSObjectReference.Dispose specifically so that it deals with catching and discarding JSDisconnectedException internally #49418 — IJSObjectReference.Dispose JSDisconnectedException handling (already fixed on main)
• Prevent JS interop after circuit disposal. Fixes #32808 #32901 — The equivalent fix for Blazor Server (RemoteJSRuntime)
• BlazorWebView: Improve WebView2WebViewManager disposal handling maui#34855 — WebView2WebViewManager disposal race condition (same family)
• BlazorWebViewHandler.iOS.cs NullReferenceException when web view has been disconnected maui#34407 — iOS NullReferenceException when WebView disconnects during initialization

[ScarletKuro]

I was about to create a similar issue, as I already opened dotnet/maui#34855 on the MAUI side. I was wondering whether it would be better to fix this at the WebViewManager / Ipc level, since WebViewManager at least knows when it gets disposed.

My problem is simple, if you close the BlazorWebView while there is (or will be due to some delay logic) an in-flight IPC message, it ends up in the AppDomain’s UnhandledException. Even though in my repro I don’t call explicitly BlazorWebView.DisposeAsync → WebViewManager.DisposeAsync, this currently doesn’t change the outcome.
This becomes especially inconvenient when you have multiple windows with BlazorWebViews that can be opened and closed. It works fine when you only have a single main window that shuts down the app on close, because in that case the exception doesn’t have time to propagate to the AppDomain’s UnhandledException.