Closed a-scollin closed 3 months ago
I've written a minimal repo project here https://github.com/a-scollin/dotnet-56892/
Note this is targeting net7 and it's also noticeable. Testing on Chrome and Firefox whilst debugging one can see many console errors when firing the mouse click multiple times in a row in quick succession. This can be triggered by holding the enter key in or more easily reproducible by running something like for(let i = 0; i < 100; i++) { $0.click() }
in the console
@a-scollin thanks for the additional details.
The first question that we have is, does it reproduce if you upgrade to 8.0? .NET 7.0 is out of support and per our support policy we don't investigate issues unless they are targeting a supported framework version.
Hi @javiercn thanks for the quick response. I've bumped the project to target .NET 8.0 and can confirm it still happens.
Thanks for contacting us. The behavior you're observing is by-design. You're trying to access the DOM elements during component disposal, at which point there is no guarantee that those haven't already been removed from the DOM. We recommend updating your code (JS) so that it takes into consideration this risk. Maybe handling any required changes through JSInterop should happen at a different stage - before the component is being disposed.
Thanks for contacting us. The behavior you're observing is by-design. You're trying to access the DOM elements during component disposal, at which point there is no guarantee that those haven't already been removed from the DOM. We recommend updating your code (JS) so that it takes into consideration this risk. Maybe handling any required changes through JSInterop should happen at a different stage - before the component is being disposed.
I am having the same problem. @mkArtakMSFT are you sure that you understood the issue properly? The problem is not that the ElementReference is null on disposal (in DisposeAsync) but that it is null in OnAfterRenderAsync when the component should be fully rendered and active. (Maybe I am the one missing something here?)
Is there an existing issue for this?
Describe the bug
Throughout Blazor examples in the docs (https://learn.microsoft.com/en-us/aspnet/core/blazor/javascript-interoperability/call-javascript-from-dotnet?view=aspnetcore-6.0#reference-elements-across-components) and in the
Microsoft.FluentUI.AspNetCore.Components
library there's this pattern of performing Js interop inOnAfterRender
/OnAfterRenderAsync
when writing components that pass anElementReference
to Js. In the docs it states :Below is an example where we've found this is sometimes not true -- it appears to happen when rendering/disposing a component that uses this pattern very quickly. This isn't a common use case although in more complex components that use this pattern we've noticed this can sometimes happen in common user flows.
Expected Behavior
We wonder if this is expected behavior and what pattern should we look to employ instead?
Reading the docs it seems like "id"-ing elements in combination with a mutation observer could solve this although it's not very elegant.
Steps To Reproduce
TestComponent.razor
It seems to happen after interop-ing to Js as the
ElementReference
is always set as expected in Blazor.SomeInterop.js
When rapidly toggling the rendering of the
TestComponent
we sometimes observe the element is null once the Js fires (happens when tabbed into button and holding down Enter)Exceptions (if any)
No response
.NET Version
8.0.11
Anything else?
Microsoft.NET.Sdk.BlazorWebAssembly
targetingnet6.0
Microsoft.AspNetCore.Components.*
are all on 6.0.31