Blazor WebAssembly - "Cannot read property 'parentNode' of undefined TypeError: Cannot read property 'parentNode' of undefined" when a focused element is hidden

[outsidergiant]

Describe the bug

Unfortunately, I cannot reopen the 26838 issue so I'm creating a new one.
In the latest .NET 6 preview version an exception occurs if an element has the onfocusout event handled, and the click is handled in the asynchronous way.

To Reproduce

Run a project with the code below and click the button:

@if(show) {
    <button @onfocusout="() => { }" @onclick="Click">Hide input</button>
}

@code {
    bool show = true;

    async Task Click() {
        await Task.Delay(1);
        show = false;
    } 
}

Exceptions (if any)

Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100] Unhandled exception rendering component: Cannot read property 'parentNode' of undefined TypeError: Cannot read property 'parentNode' of undefined at O (https://localhost:44354/_framework/blazor.webassembly.js:1:13297) at V.applyEdits (https://localhost:44354/_framework/blazor.webassembly.js:1:17125) at V.updateComponent (https://localhost:44354/_framework/blazor.webassembly.js:1:16469) at https://localhost:44354/_framework/blazor.webassembly.js:1:49688 at Object.he._internal.renderBatch (https://localhost:44354/_framework/blazor.webassembly.js:1:50058) at Object.ct [as invokeJSFromDotNet] (https://localhost:44354/_framework/blazor.webassembly.js:1:52281) at _mono_wasm_invoke_js_blazor (https://localhost:44354/_framework/dotnet.6.0.0-preview.4.21253.7.js:1:211543) at <anonymous>:wasm-function[5707]:0xdfd2f at <anonymous>:wasm-function[5802]:0xe1d70 at <anonymous>:wasm-function[2185]:0x459a5 Microsoft.JSInterop.JSException: Cannot read property 'parentNode' of undefined TypeError: Cannot read property 'parentNode' of undefined at O (https://localhost:44354/_framework/blazor.webassembly.js:1:13297) at V.applyEdits (https://localhost:44354/_framework/blazor.webassembly.js:1:17125) at V.updateComponent (https://localhost:44354/_framework/blazor.webassembly.js:1:16469) at https://localhost:44354/_framework/blazor.webassembly.js:1:49688 at Object.he._internal.renderBatch (https://localhost:44354/_framework/blazor.webassembly.js:1:50058) at Object.ct [as invokeJSFromDotNet] (https://localhost:44354/_framework/blazor.webassembly.js:1:52281) at _mono_wasm_invoke_js_blazor (https://localhost:44354/_framework/dotnet.6.0.0-preview.4.21253.7.js:1:211543) at <anonymous>:wasm-function[5707]:0xdfd2f at <anonymous>:wasm-function[5802]:0xe1d70 at <anonymous>:wasm-function[2185]:0x459a5 at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[Int32,RenderBatch,Object,Object](String identifier, Int32 arg0, RenderBatch arg1, Object arg2, Int64 targetInstanceId) at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[Int32,RenderBatch,Object](String identifier, Int32 arg0, RenderBatch arg1) at Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer.UpdateDisplayAsync(RenderBatch& batch) at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()

Further technical details

• ASP.NET Core 6.0.0-preview.4.21253.5
• VS 2019

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[SteveSandersonMS]

Thanks for reporting this. However, the issue doesn't repro when I try it using your sample code and the current preview build.

Since your report implies you were using preview 4, and the bug #33997 was actually fixed in preview 4, it's not completely clear why you were still able to repro it. My best guess is that you were using a nightly build of preview 4 from before the bugfix landed. If it's for some other reason, I'm not sure what the reason would be.

I'm going to mark this as "no repro" for now, but if you are still able to repro the issue with the current 6.0 preview 6, it would be great if you could let us know what additional steps are needed besides the code you posted above, since the code posted above doesn't seem to do it.

Thanks again!