The custom status message of the user does not get hidden by the banner even when the post that the user saw is gone, hence making it not visually appealing.
Attached is a picture of the problem:
Click on a user’s custom status, and scroll up, until the post is gone from sight. Then, you will still be able to see the status mssage in front of the banner at the top of the page.
Bug appears at this link:
(I am not sure if this is just me)
Browser/OS/Device:
Replit app/Android /Samsung Galaxy
Similar occurrences:
I have found that it is in front of the bar where you can go back or go forward.
Here’s a handy picture:
This happens not only with user status tooltips, but also with some other tooltips that are also implemented using the DTooltip component
On desktop, we use the mouseenter event as a tooltip trigger. When the mouse leaves the tooltip, it disappears, so everything works smoothly.
On mobile, the trigger for tooltip is a click, and for tooltip to disappear user have to click outside the tooltip. Because of that, the tooltip doesn’t disappear when scrolling. This is the default behavior of tooltips made using the tippy.js library that we use under the hood.
I’m working on the fix currently, and already have a working draft. The solution will be to hide the tooltip when scrolling on mobile. And that’ll fix all the DTooltip based tooltips.
We’ve just merged the fix, it’s in the main branch now. Remember it only solves the problem in topics, there is a similar problem in chat, which will be addressed separately later.
Hey everyone!
This appeared again on another forum.
Other forums like this and Ask fades the header, but that forum does not.
May I add that if you scroll up quickly when the status is still being shown, it will overlap, but the header won’t react fast enough to hide it.
As you can see, the custom status strikes again!
I have found that it is in front of the bar where you can go back or go forward.
Here’s a handy picture:
@NateDhaliwal thank you for reporting these problems!
Note that, more precisely, the problems are related to components that we use for showing rich tooltips across the app. We use rich tooltips for showing status, but we also use them for other things. So potentially the similar issues can be reproduced with other tooltips too. The fix I provided above fixed only the most general cases.
We’re currently working on more changes to the components for rich tooltips, so there’ll be more updates here. We’ll take care of these problems.
