I’m currently seeing some issued with our admin interface, where people on Intel CPU’s being shown the “the tab has crashed” kind of dialog when using a LiveView form. The background is that we use the Ecto sort and delete params, interactions need to be processed, otherwise I’d just change it to not have any interactive features.

The issue is not on the receiving end, that’s significantly much faster, but when LiveView does its processing before dispatching to the server. This screenshot is on a M3 Pro.

runtime1951×229 34.9 KB

I don’t know why dispatchClickAway is wrapping all this, since there’s no such event on the page
I tried digging deeper but as you know with JS, it’s usually a very long list of anonymous functions with minified names.

Looking at Node count it varies between 80-800K. Yes that’s 10x, for some reason LiveView or Chrome, unclear which, don’t clean up the tree after navigating/getting updates. It seems to be reliant on a GC to run.

The form is quite straight forward.

Schema (120 entries), 
|---- SubSchema (can vary, but between 0 and 10 items)
|---- SecondSubSchema (0-3 items)

So at most one level deep, but you can add and remove them dynamically. Processing times on the server side are fast enough that it doesn’t matter, less than 20ms, even in dev-mode.

Curious as to if people have some good ideas on how to debug this.