Breaking DOM generates endles stream of runtime errors

Hey community! I’m looking for ideas on the following problem.

I’m trying to figure out a way to detect browser extensions that break virtual DOM (part of the GitHub - jinjor/elm-break-dom effort). The difficulty is that I don’t have access to browsers of users that have issues and can’t easily tell what extensions they have. From Sentry I know the errors happen, but without much details. So I thought it would be smart to capture a snapshot of the DOM as HTML string whenever there is a runtime error. There is a way to store it in a Sentry report. Having those snapshots I could look for traces of extensions (class names, etc.).

In principle I got it working. The problem is that when something messes up the DOM controlled by Elm, there isn’t just one exception thrown. It seems like they are being thrown in an endless loop - thousands per minute.

Here is a sample application that break DOM and demonstrates it (source code). If you click on any of the buttons, the errors will start. Open the console to see, but be careful - it will quickly consume a lot of memory.

So sending all those errors to Sentry with relatively large payloads will quickly overflow my account.

I will appreciate any thoughts about it.

It’s unclear this will ever be solved. The fix is easy though, just search this forum. Basically prevent Elm from managing the element, but it should just manage a

inside , easy fix, fixes 100% of the know problems.

Thanks @berend. Please note that I’m not looking to fix the DOM related errors. I’m looking for a sane way to report them. It’s kind of a meta problem.

Yep, if you search the forum, you’ll find some ideas on where to collate them.

I would try to implement some logic in beforeSend.

1 Like

I found a beforeSend example here: Implement client-side rate limiting / avoid sending the same error repeatedly · Issue #435 · getsentry/sentry-javascript · GitHub

1 Like

Thanks @lydell and @encetamasb. I followed your advice and this is what I came up with:

It seems to be working and I will suggest to apply this method to our real application. Hopefully we will get some useful data soon.

If anyone has other thoughts about analysing DOM related errors I am still very interested. In general I want to follow the advice of @evancz and first collect and analyse data, then possibly come up with a solution.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.