JavascriptException: Aborted / unhandled promise rejection when navigating away during MapView initialization

[fargherm]

Description

When navigating away from a page containing a MapView while it is still initializing (specifically while the WebMap / basemap is loading), an unhandled promise rejection escapes into the browser console and can surface as an application error:

Uncaught (in promise) Error: dymaptic.GeoBlazor.Core.Exceptions.JavascriptException: 
Aborted: Failed to load web map
  at MapView.OnJavascriptError(...)

This happens because esri.WebMap#load() is aborted mid-flight, which GeoBlazor correctly detects as an AbortError, but then calls back into .NET via OnJavascriptError using invokeMethodAsync — at which point the MapView component has already been disposed. The resulting unhandled promise rejection bypasses ErrorBoundary entirely since it originates outside Blazor's render cycle.

Environment

• GeoBlazor Version: 4.4.4
• Blazor Hosting Model: WebAssembly

Steps to Reproduce

1. Place a MapView with a WebMap (portal item) on a page
2. Navigate to that page
3. Immediately navigate away before the map finishes loading
4. Observe unhandled promise rejection in the browser console

Reproduced on Official Demo Site

This issue is reproducible on the GeoBlazor demo site itself, confirming it is not caused by
consumer code. Steps:

1. Navigate to a map page on the GeoBlazor samples site
2. Immediately navigate away before the map finishes loading
3. Observe the same errors in the browser console:

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'reject')
    at vb.start (LayerLayerViewInfo.js:5:2796)

Error building map view: TaskCanceledException_ctor_DefaultMessage
    at Microsoft.JSInterop.JSObjectReferenceExtensions.InvokeVoidAsync(...)
    at dymaptic.GeoBlazor.Core.Components.Views.MapView.BuildMapView()

The #blazor-error-ui error banner is suppressed on the demo site (likely via CSS),
but the underlying unhandled exceptions are still visible in browser DevTools, confirming
the root cause is present regardless of the UI workaround.

The TypeError: Cannot read properties of null (reading 'reject') originates in the ESRI
SDK's own layer view promise chain being torn down mid-flight, suggesting the fix needs to
account for both GeoBlazor's .NET disposal guards and graceful handling of the ESRI SDK's
async teardown.

Clicking between https://samples.geoblazor.com/navigation and https://samples.geoblazor.com/drawing without letting the maps fully render will show the errors in the dev tools and an actual error message on screen briefly appears.

Expected Behavior

OnJavascriptError (and any other JS→.NET callbacks) should check IsDisposed before invoking .NET methods. An AbortError resulting from component disposal should be treated as expected, not exceptional.

Actual Behavior

Uncaught (in promise) Error: dymaptic.GeoBlazor.Core.Exceptions.JavascriptException: Aborted: Failed to load web map
   at dymaptic.GeoBlazor.Core.Components.Views.MapView.OnJavascriptError(:5178/JavascriptError error)
    at w.endInvokeDotNetFromJS (blazor.webassembly.js:1)

Also logged:

esri.WebMap #load() Failed to load web map e {name: 'AbortError', details: undefined, message: 'Aborted'}
Error building map view: TaskCanceledException_ctor_DefaultMessage

Suggested Fix

In OnJavascriptError and similar JS-invokable callbacks, add a disposal guard before invoking .NET:

if (IsDisposed) return;

Similarly, the JS interop layer could catch AbortError specifically when the view is being torn down and suppress the callback rather than propagating it back to .NET.

Workaround

Currently working around this with a combination of:

• Navigation.RegisterLocationChangingHandler to set _renderMap = false and yield before navigation completes, giving Blazor time to unmount the component
• An ErrorBoundary wrapper around MapView
• A JS unhandledrejection filter targeting the specific error message

None of these are ideal as they operate at the wrong layer and are fragile against future library changes.

[TimPurdum]

Thanks @fargherm. We're aware of the issue as you could tell from the suppression in the samples, but have been debating the best approach to handling it. I'll take a look at your suggestion of checking for AbortError and Disposed state in the JSInvokable callbacks, that sounds promising!