Blazor Exception clicking browser back button when focus on a bound input

[frankabbruzzese]

In Blazor WebAssembly 3.2 applications running in Chrome, when the focus is in an input field (say InputNumber) that is inside and EditForm, an exception is thrown if the user clicks the browser back button that returns to a previous page of the same Blazor application.

From the error message that mentions an element that is not found, probably the blur event is processed when the input has been destroyed, so Blazor attempt to apply validation classes to the input fails.

To Reproduce

Scaffold the standard WebAssembly project in Visual Studio

Then replace the Counter page with the code below:

@page "/counter"

<h1>Counter</h1>

<EditForm Model="currentCount">
    <InputNumber @bind-Value="currentCount"/>
</EditForm>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Then run the application and go from the Home to the Counter page

Edit the input fields, and change the 0 value to, say 1, (by editing the field, not with the button)

Without changing the focus from the input click the browser back button.

The application returns to the home page but an exception is thrown, and the home page appears blank!

Pay attention! If the input loses focus before clicking the browser back button the exception is not thrown!

Exceptions (if any)

Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100] Unhandled exception rendering component: Unknown edit type: 0 Error: Unknown edit type: 0 at e.applyEdits (https://localhost:44381/_framework/blazor.webassembly.js:1:15076) at e.updateComponent (https://localhost:44381/_framework/blazor.webassembly.js:1:12948) at Object.t.renderBatch (https://localhost:44381/_framework/blazor.webassembly.js:1:1704) at Object.window.Blazor._internal.renderBatch (https://localhost:44381/_framework/blazor.webassembly.js:1:34848) at _mono_wasm_invoke_js_unmarshalled (https://localhost:44381/_framework/wasm/dotnet.3.2.0.js:1:172099) at wasm_invoke_iiiiii (:wasm-function[3160]:0x9b33d) at icall_trampoline_dispatch (:wasm-function[5777]:0xfe711) at mono_wasm_interp_to_native_trampoline (:wasm-function[4607]:0xca81d) at ves_pinvoke_method (:wasm-function[3209]:0x9cd40) at interp_exec_method (:wasm-function[1120]:0x2598d) Microsoft.JSInterop.JSException: Unknown edit type: 0 Error: Unknown edit type: 0 at e.applyEdits (https://localhost:44381/_framework/blazor.webassembly.js:1:15076) at e.updateComponent (https://localhost:44381/_framework/blazor.webassembly.js:1:12948) at Object.t.renderBatch (https://localhost:44381/_framework/blazor.webassembly.js:1:1704) at Object.window.Blazor._internal.renderBatch (https://localhost:44381/_framework/blazor.webassembly.js:1:34848) at _mono_wasm_invoke_js_unmarshalled (https://localhost:44381/_framework/wasm/dotnet.3.2.0.js:1:172099) at wasm_invoke_iiiiii (:wasm-function[3160]:0x9b33d) at icall_trampoline_dispatch (:wasm-function[5777]:0xfe711) at mono_wasm_interp_to_native_trampoline (:wasm-function[4607]:0xca81d) at ves_pinvoke_method (:wasm-function[3209]:0x9cd40) at interp_exec_method (:wasm-function[1120]:0x2598d) at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[T0,T1,T2,TResult] (System.String identifier, T0 arg0, T1 arg1, T2 arg2) <0x2cb0b48 + 0x00046> in :0 at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[T0,T1,TResult] (System.String identifier, T0 arg0, T1 arg1) <0x2cb0a68 + 0x00014> in :0 at Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer.UpdateDisplayAsync (Microsoft.AspNetCore.Components.RenderTree.RenderBatch& batch) <0x2cb0970 + 0x0001e> in :0 at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue () <0x2b67670 + 0x000f2> in :0

Further technical details

• ASP.NET Core version 3.1
• Blazor 3.2
• Chrome browser

[mkArtakMSFT]

Thanks for contacting us.

@SteveSandersonMS did this get fixed already in 5.0? If yes, please close this issue. Thanks!

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[frankabbruzzese]

@mkArtakMSFT , I am almost sure the issue depends on the fact that when you click the back button the browser doesn't generate a blur event. In fact, if the page change is performed with a link, or with a button that performs the back via JavaScript, no issue occurs, because the blur event occurs before the link/button click is processed. Probably, the problem is caused by the handler that processes the input change, since this handler is run at a later time when the page has been partially or completely destroyed

[mkArtakMSFT]

Hi. Thanks for contacting us. We're closing this issue as there was not much community interest in this ask for quite a while now. You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.