Blazor WASM leaves detached nodes

[Dargazo]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

There seems to be a memory leak when creating/destroying elements inside an if statement on user input.

Expected Behavior

No detached nodes when elements are dynamically destroyed/created. When

Steps To Reproduce

I've created a repro solution here: https://github.com/Dargazo/BlazorDetachedNodeRepro/tree/master

• Start the app in (tested in Edge/Chrome)
• Open Developer tools (F12)
  -- Open the Memory tab
  -- Select the 'Detached elements' option
• Press the 'Take snapshot' button
• Observe: Some detached nodes, this is our baseline
• On the app page, increment the CurrentNumber using the rendered 'InputNumber' element
• Observe: two new InputElements are now rendered
• Now back in the developer tools, press the 'Take snapshot' button again
• Observe: a new <input .... _bl_2> element is now also detached.
• Back on the app, decrement the CurrentNumber using the rendered 'InputNumber' element
• Take another snapshot and
• Observe: another two <input ... > elements are added.

Note: Pressing the 'Click me Up' / 'Click me Down' seem to properly clear the input elements and not leave them detached.
Note: clicking inside one of the InputNumber elements, and then clicking the 'Click me Up'/'Click me Down' buttons also leaves detached nodes

Exceptions (if any)

No response

.NET Version

9.0.201

Anything else?

This is a minimal repro. We came across this issue in our application, where we (re)create UI based on selected elements and use switch statements to decide what components to render. This rose up to sometimes hundreds of detached nodes when switching between elements.

[Dargazo]

For clarity, I'll include the relevant code here:
The main issue is that Blazor seems to leave detached nodes if you use the InputNumber elements to increase/decrease the CurrentCount variable, whereas this is not happening if you use the buttons.

<EditForm Model="model">
    @if (model.CurrentCount < 5)
    {
        <InputNumber @bind-Value=model.CurrentCount />
    }
    else
    {
        <InputNumber @bind-Value=model.CurrentCount />
        <InputNumber @bind-Value=model.CurrentCount />
    }
</EditForm>
<p role="status">Current count: @model.CurrentCount</p>

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

<button class="btn btn-primary" @onclick="DecrementCount">Click me Down</button>
@code {

    class TempModel
    {
        public int CurrentCount { get; set; } = 4;
    }

    TempModel model { get; set; } = new();


    private void IncrementCount()
    {
        model.CurrentCount++;
    }
    private void DecrementCount()
    {
        model.CurrentCount--;
    }
}

[javiercn]

@Dargazo thanks for contacting us.

Are you able to see what JavaScript bits are holding on to the elements?

In general, detached elements aren't always an indication of a memory leak, and memory leaks aren't always caused by detached elements.

It might be that we are holding on to the elements in the JS side to avoid recreating them at a later point. Have you tried navigating to a separate page, and seeing if the elements go away?

[Dargazo]

@javiercn Thank you for your time, and response.

to answer your second question first:

I added 2 'empty' pages to the repro project. When I navigate to them, all mentioned detached elements remain detached and visible in the dev tools.

Furthermore, the whole form is now detached also (!) This only seems to happen when I interact with the input elements, and then navigate away.
This does not happen if I use the "Click me up/down" buttons.
I've included a screen capture here:

Note: The same behavior is present if you press the 'Collect Garbage' button between taking snapshots

As for the JavaScript bits holding on to them, I don't really know how to make sense of this.
Here is a screenshot of a Heap snapshot with a detached input element selected (Note that this was taken on a new run compared to the gif above)

[javiercn]

@Dargazo thanks for the additional details.

Doing a bit of inspection over the code based on the screenshot, I can't tell for sure what's going on. The event handler should have been disposed here so I think this might be worth investigating further.

If you want to dig deeper yourself into this, the event handler should have an eventId associated with it, and you should be able to see a call to disposeEventHandler with that ID after a render. That gets called here after a render is triggered (for example after typing something and handling onchange)

It's not clear to me if this is not triggering or if the report about the snapshot is incorrect in some way.