Monitor plugin causes "Maximum call stack size exceeded" / browser tab freeze via jQuery UI tooltip destroy loop, triggered by core AJAX tab navigation (loadPage)

[fidrom75]

Environment

• Cacti version: 1.2.31
• Monitor plugin version: 2.8.1
• PHP version: 8.2.31
• OS: Raspberry Pi OS / Debian (aarch64)
• Browser: Chrome 149.0.0.0 (Windows)
• Web server: Apache 2.4.67 (Debian), prefork MPM

Description

When navigating to the Monitor plugin page (or between pages that lead into it) using Cacti's core AJAX-based tab navigation (loadPage() in layout.js), the browser tab intermittently freezes completely (spinning tab indicator, unresponsive UI). CPU/network monitoring on the server confirms the server itself is idle at the time of the freeze (no busy Apache workers, no active MySQL queries, normal load average) — the issue is entirely client-side.

The browser console shows a RangeError: Maximum call stack size exceeded, originating from a recursive loop between jQuery's remove()/trigger() and jQuery UI's tooltip _destroy()/destroy() handlers, apparently triggered when the Monitor plugin's periodic AJAX content refresh (content() in monitor.php, _updateContent in jquery-ui.js) tries to tear down tooltip-bound elements while Cacti core's own loadPage() AJAX navigation is also manipulating the DOM.

Steps to reproduce

1. Have several devices (~20-100) configured and visible in the Monitor plugin overview, each triggering an ajax_status request and tooltip binding.
2. Navigate into the Monitor page via Cacti's core tab navigation (clicking menu items, which uses AJAX loadPage() rather than a full page reload).
3. While the Monitor page's periodic auto-refresh is active, navigate away and/or hover over device status icons (tooltips) around the time of a refresh.
4. Intermittently, the browser console logs repeated Uncaught RangeError: Maximum call stack size exceeded originating from jquery.js camelCase/Data.get/trigger/triggerHandler calling into jquery-ui.js _destroy/destroy/remove/handlerProxy, and the tab becomes fully unresponsive (spinning indicator).
5. A hard refresh (Ctrl+Shift+R) does not resolve the issue — it is not a stale-cache problem, it reproduces with fresh assets.

Expected behavior

Monitor plugin's periodic refresh and Cacti core's AJAX tab navigation should not conflict; tooltip widgets should be destroyed/recreated without triggering recursive events, and the page/tab should remain responsive.

Actual behavior

Browser tab hangs indefinitely (JS main thread blocked by stack overflow loop) until the tab/browser is force-closed and restarted. No server-side resource issue is observed during the freeze (confirmed via mod_status extended output and SHOW FULL PROCESSLIST during multiple occurrences).

Console stack trace (excerpt)

Uncaught RangeError: Maximum call stack size exceeded
    at String.replace (<anonymous>)
    at camelCase (jquery.js:3954:44)
    at Data.get (jquery.js:4035:52)
    at HTMLAnchorElement.dispatch (jquery.js:5106:14)
    at HTMLAnchorElement.<anonymous> (jquery.js:4949:28)
    at Object.trigger (jquery.js:8629:12)
    at jQuery.triggerHandler (jquery.js:8713:24)
    at jQuery.cleanData (jquery-ui.js:54:15)
    at remove (jquery.js:5969:11)
    at jQuery.remove (jquery.js:6072:10)
    at Object._destroy (jquery-ui.js:18717:19)
    ...
    (repeats hundreds of times, alternating between remove/_destroy/destroy/trigger/triggerHandler)
    ...
    at XMLHttpRequest.send
    at send (jquery.js:9940)
    at ajax (jquery.js:9521)
    at content (monitor.php:610)
    at _updateContent (jquery-ui.js:18448)
    at open (jquery-ui.js:18434)
    ...
    at loadPage (layout.js:2263)

Additional notes

• Confirmed not caused by browser cache (hard refresh with cache clear does not resolve it).
• Confirmed not a server-side performance/resource issue (Apache server-status, SHOW FULL PROCESSLIST, top, and iostat all show the server idle during the freeze).
• Happens intermittently, seemingly correlated with tooltip hover + periodic AJAX refresh timing, and/or navigating via core's AJAX tab loader into/out of the Monitor page.
• This may also involve Cacti core (layout.js loadPage()), not purely the Monitor plugin — happy to help narrow this down further if useful.

Regards Roman

[TheWitness]

What theme are you using? How did you install Cacti from source or from a Debian package?

[TheWitness]

Might be a Chrome issue. I'm not seeing it. I was on 149.0.7871 before and not seeing it, now on this and the same:

[TheWitness]

If you installed from Debian packaging, I get worried as they are generally using system versions for a number of things which introduces some unverified code paths. They do a great job, but sometimes these things happen.

[fidrom75]

I am using the Paw Theme but there is no difference when i use another Theme like Classic... same problems
i've installed cacti via manual downloading *tar.gz files from cacti.net and installed evereything manually as i always do since cacti 1.1.xx
and it is definatley not a Chrome issue as i have the same problem on Firefox on Win11 and Safari on MacOS

[TheWitness]

Okay perfect. There was a release of 2.9 today. Let me know if that changes anything. Make sure you are able to clear your cache. Firefox has some nice add-ons for that.

[fidrom75]

Thanks, the newest Monitor Plugin 2.9 is doing his job now without any problems!