Browser freezes with "Page unresponsive" because of react-tooltip

[revov]

Hello guys, we are facing a tough to reproduce issue with our application freezing the whole page (in some sort of an infinite loop) in rare occasions. We are building an enterprise application with thousands of elements on the screen and many tooltips. The problem seems to appear after upgrading to the latest version of react-tooltip when we do filtering on a large table with many cells with tooltips.

Pressing F8 to open the devtools when the page becomes unresponsive leads us to React Fiber callstack, which after some digging points us to the root of the infinite loop - the autoUpdate from "@floating-ui/dom" triggers updateTooltipPosition over and over in an infinite loop, presumably on an anchor element that's no longer present in the DOM.

I don't have a way of reliably reproducing this let alone isolating it in a sandbox so I can't open an issue, but any ideas on what I can do to debug this next time it happens would be really appreciated.

@gabrieljablonski, probably related to this commit - 3b411f0

[gabrieljablonski]

Hey @revov.

As you can see here, it is possible to disable autoUpdate usage by setting globalCloseEvents.resize (or closeOnResize, if on a version prior to v5.22.0).

This is not optimal, since you might not wish to have the tooltip close automatically when scrolling, though it's a good starting point to figure out this specific issue. Since you can't reproduce it reliably, it might be a little tricky to know for sure autoUpdate is the sole reason for the problem.

---

Feel free to add more info here to see if we can help you figure something out, but if at any point you're able to reliably reproduce this, please open an issue with the details.

We may also consider adding a new disableAutoUpdate prop, but I'm not sure yet if that's a good idea.

[gabrieljablonski]

The docs for the globalCloseEvents prop:

https://react-tooltip.com/docs/options#:~:text=close%20the%20tooltip-,globalCloseEvents,-Record%3Cstring%2C%20boolean

[revov]

@gabrieljablonski, thanks for the quick answer. We have tried the globalCloseEvents.resize flag which seems to work around the autoUpdate issue and so far we've not been able to reproduce the freeze (with the default parameters we've had a reproduction scenario where we had it occur in 70% of the cases in under 10 seconds).

I still believe there is an issue with the default Tooltip settings (probably calling autoUpdate on a stale anchor or failing to clean it up properly when the anchor is removed from the DOM). Will keep you updated if we manage to figure out what exactly is going on.

[supra28]

@revov I just hit a similar issue too and was able to find the root cause, see if your problem is the same
Same as you we have a data heavy application with a huge data table and a few modals with tooltips everywhere, we observed that continuously using the application over time (moving around the paginated table and opening and closing the modal) would make the page unresponsive and after a bit of debugging I found that the browser was storing the DOM nodes and a huge number of event listeners for nodes not even present in the DOM anymore (nodes of closed modals and pages of table not on the scree).

After a little more digging we found that, we never unmount React-Tooltip and it keeps attaching event listeners to DOM nodes and never clears it since its never unmounted and since the event listeners are never removed the RAM usage keeps on increasing eventually making the page unresponsive.

[revov]

The intended usage of the library is not to have a separate component for every tooltip you need, but more like - 1 per tooltip type (which very often is just 1 for the whole app). That's why they rely on data- tags and mutation observers to attach and detach listeners, as that's more performant. Whether things are cleaned up properly - I don't know, probably not - otherwise we wouldn't have had an issue, but I doubt that the proper solution is to have a separate instance that we unmount for every route in your application.

[ToyboxZach]

I just ran into a very similar issue that was triggered by my tests.

Essentially I had a component that was showing and showing its tool tip, and then after a short delay it unmounts and hides it.

This was fine in an physical case I could make, but my test would lock up about one out of every 3 attempts at this, and seemed to be more likely the more other animations I had going on, so it was some type of race condition.

I believe that the timing ended up being that as the tooltip was animating away the component got unmounted. I have no way to make a minimal repro case, so I don't want to make a bug for it, but just thought I would help this conversation

Oddly was seeing this on 5.26.3 but after seeing this issue #1182 I decided to try 5.26.0 and now I cannot repro the issue again.

[gabrieljablonski]

Not much to go off of here.

Since reverting to 5.26.0 seems to have fixed the issue for you, I find it unlikely that it's related to the original complaint from this discussion.

As you can see on #1182, I was unable to reproduce the issue reported by the author, so I'm not sure that's the case either.

So unfortunately, unless you can provide a reproducible example, there's not much to do about this now.

The best I can suggest is to check if you're not using too many tooltips on your application. See the troubleshooting page section about this.