I use chrome and this does not occurs for me.

It's a known issue. The JS is horribly slow in certain OS/browser combinations (Windows + Chrome browser seems to main issue?). I have reported the tooltip issue myself in the old v5 beta bug tracker, but it's not resolved yet.

You can read what @Matt Finger posted in this other bug report about the root cause:

Edited February 25Feb 25 by teraßyte
typo

I just tested the tooltips with Opera and the lag is even worse there: the normal title attribute is first displayed, and only after a few seconds the JS kicks in and replaces the title attribute with _title (underscore) to show the tooltip. 👀

EDIT

Opera One (version: 117.0.5408.39)
Windows 10 64-bit
Chromium Version: 132.0.6834.209

Edited February 26Feb 26 by teraßyte

Will this issue be addressed in version 5.0.4? A lot of users use Chrome, and the experience is poor due to these delays.

I've added this bug report too, just to add context to the other report. There is nothing specific I can see related to 504, but please feel free to check out the beta

 

I've added this bug report too, just to add context to the other report. There is nothing specific I can see related to 504, but please feel free to check out the beta

In the latest beta version, the problem still exists. In the Chrome browser, when I hover over the icons in the header for messages, notifications, or reactions when marking them, and the description appears, there is a significant lag. Try moving the cursor over these buttons, and you will experience the issue.

 

In the latest beta version, the problem still exists. In the Chrome browser, when I hover over the icons in the header for messages, notifications, or reactions when marking them, and the description appears, there is a significant lag. Try moving the cursor over these buttons, and you will experience the issue.

Im not on my end on Chrome but I am also using a different version of windows. This is not to dismiss your issue. Im just saying Im not experiencing it myself.

I face this problem as well and it is annoying to a great extent

We have some updates for this upcoming. Wont be 5.0.4 as thats already too far out the door :)

 

We have some updates for this upcoming. Wont be 5.0.4 as thats already too far out the door :)

Thanks for the update. At least we know something is coming. 🙃

I'll add that the problem still exists in version v5.0.5, but I've noticed something interesting that might help identify the issue. This delay occurs exclusively on the homepage (even with the default theme). When users enter any topic, the delays disappear completely.

 

I'll add that the problem still exists in version v5.0.5, but I've noticed something interesting that might help identify the issue. This delay occurs exclusively on the homepage (even with the default theme). When users enter any topic, the delays disappear completely.

This is due to JavaScript, the more data the page contains, the slower it is, so this is not new

I wasn't able to naturally reproduce this on any of my devices, however I've now been able to by throttling Chromes CPU by 20x, which makes it run very slow.

The culprit was a CSS selector, and surprisingly not a JS issue as some have speculated. It's likely a result of poor implementation of the :has() selector in Chrome. The tooltips now appear instantly for me when using a throttled version of Chrome.

Before/after videos are below, and the fix should hopefully arrive in the next update if testing goes well 🤝

Screen Recording 2025-03-26 at 9.43.14 am.mov 392.7 kB ·

Screen Recording 2025-03-26 at 9.42.40 am.mov 436.5 kB ·

@Ehren Could you post the CSS change if it's not too much trouble?

The slow/sluggish problem affects more than just tooltips: editors, messenger, checkboxes, etc. I assume this CSS you mentioned was the root cause of everything, but I'd like to test it locally to verify it. 🙃

Edited March 26Mar 26 by teraßyte

Sure. This code was removed from 4-mobile-footer.css in favour of a different solution.

body:has(.ipsEditor:focus-within) .ipsMobileFooter{
	transform: translateY(100%);
}

@Ehren Unfortunately, while this change helps with the editor falling behind when I type fast, the tooltips are still extremely sluggish for me locally in Chrome (v134 + Windows 10):

This GIF image is in real time. You can see the tooltips still lag behind a lot. Even the title attribute shows before it's converted to a tooltip.

Also, if you look at when I go from the edit/pencil button to the wrench one, you'll see the tooltip is in the wrong location.

When I go in the opposite direction (badge => wrench), the location is correct, though.

===

The above GIF is from a custom application, but I can reproduce the same behaviour on the core Applications page.

Edited March 26Mar 26 by teraßyte

Apologies, I didn't realse you'd be testing the ACP too. The ACP requires a different code change. The one I provided is for the front-end.

There are 4 instances of body:has() in the CSS. I've removed all 4 for the update. This is a notable one from the ACP:

body:has(#acpLiveSearchResults:not([style*="block"])) .acpSearch__close{}

@Ehren Thanks. I could find only 2 instances with a quick search, but even with those commented, the tooltips are already twice as responsive. I'll eagerly wait for the next (beta) version. Fingers crossed. 🤞

 

@Ehren Thanks. I could find only 2 instances with a quick search, but even with those commented, the tooltips are already twice as responsive. I'll eagerly wait for the next (beta) version. Fingers crossed. 🤞

Can you confirm if this issue has been fixed or not

for me is fixed

Edited Thursday at 08:53 PM4 days by PanSevence

 

Can you confirm if this issue has been fixed or not

You can test yourself on this site. It's been updated to 54.0.5 Beta 2, which contains the fix.

The editor is pretty smooth for me now. 🙃