rtivital
commented
2 years ago I do not have a Linux computer, cannot resolve that, works fine on windows and macos.
Closed Nantris closed 1 year ago
rtivital
commented
2 years ago I do not have a Linux computer, cannot resolve that, works fine on windows and macos.
nmay231
commented
2 years ago @Slapbox Your sandbox works fine for me on Ubuntu 22.04 (Wayland I think?) with Chrome 104.0.5112.101. I have tried hovering/unhovering multiple times, switching focus between tabs and windows then trying again, and hovering while focused on another window.
Try opening an incognito window to see if an extension is causing the problem or something.
Nantris
commented
2 years ago Thanks for testing @nmay231. Unfortunately it's definitely not due to any extension as I'm able to reproduce it in Chrome and in Electron, but maybe it's something related to GPU rendering on Linux?
I've been trying to test on a third machine but haven't been able to get a Chromium browser installed yet due to some dumb bug in Manjaro.
I'll update with further findings as I can.
Nantris
commented
2 years ago Got the third machine to run Chromium and the tooltips do work there.
@nmay231 would you be so kind as to screenshot the first two sections under chrome://gpu?
Here's mine on one of the problem machines:
The only immediate difference I notice is that the problem machine I'm looking at currently shows Multiple Raster Threads: Enabled and the working machine does not.
I imagine this must be some issue with floating-ui, but we use it in other areas and it works fine - though perhaps the versions vary. If I can pinpoint the difference between the working/non-working machines I'll look into opening an issue there (assuming it is a floating-ui issue.)
nmay231
commented
2 years ago @Slapbox Sure thing.
Doesn't look like Multiple Raster Threads: Enabled is the issue, unfortunately.
rtivital
commented
2 years ago Okay, the issue does not seem to be reproducible, closing it
Nantris
commented
1 year ago @rtivital the issue does not appear to affect Floating tooltips, which makes me think this is indeed something that Mantine can probably fix - unless this is just because Floating are "controlled," which seem to be unaffected.
I very much doubt my machine is the only one in the world with this problem, but the likelihood of it being reported by end users is rather low since they won't know the tooltip is missing and will just assume there's no tooltip. I think we should use the opportunity presented by having a developer with a machine that exhibits the problem rather than writing it off as a non-issue.
Floating works repro: https://codesandbox.io/s/strange-paper-yrvko1?file=/src/App.tsx
Also: If I remove the .Floating part from the code while you're hovering the Floating tooltip, I see the uncontrolled/non-floating tooltip work, but once the mouse leaves the element, it never works again. It could be an artifact of the CodeSandbox refresh logic, or it could be a real lead. Video.
rtivital
commented
1 year ago Okay, I still cannot reproduce the issue in Chrome on macos and Windows, so I cannot do much about it
Nantris
commented
1 year ago @rtivital understood. I appreciate you re-opening the issue. I've added a short screen capture to the edit in my previous comment and I'll continue trying to make progress on this as possible.
Additional findings:
@floating-ui/react-dom-interactions@floating-ui/react-dom-interactions is not the issue useTooltip - onChange only fires when the mouse moves off the tooltip, not when it moves onto it
onChange does fire, _opened is always falseopened is always false in the return statement as wellnmay231
commented
1 year ago @Slapbox FYI, I have no issues with the sandbox using another linux computer (Ubuntu 22.04, Chrome 107.0.5304.87).
Some tips for debugging, you can stop the tooltips from disappearing using the debugger: setTimeout(() => {debugger}, 3000), and then resume execution in the sources panel.
Nantris
commented
1 year ago @nmay231 yeah my other Linux machine also has no trouble - but this machine won't show them whether I use --disable-gpu or --use-vulkan --enable-features=Vulkan - none of them make a difference. If/when I get to the bottom of this, I think the cause will be something unexpected because it doesn't really strike me as a GPU problem anymore, since I proved to myself that the Mantine floating tooltip works, Floating UI interactions work, and since the uncontrolled tooltip is capable of showing in at least the one circumstance when live-editing in the sandbox.
Some tips for debugging, you can stop the tooltips from disappearing using the debugger: setTimeout(() => {debugger}, 3000), and then resume execution in the sources panel.
I guess the trouble is that the tooltips won't appear to begin with except under the edge case of live-editing on CodeSandbox.
Edit: Is there any way to trigger a callback when the opened state changes in Mantine so I can confirm that the opened state actually changes?
nmay231
commented
1 year ago @Slapbox I guess you could use an onMouseOver event on a child component of the Tooltip to activate the debugger.
Also, does the element at least pop in even if it's invisible? After the debugger is active, it's easiest to ctrl-f in the elements panel for the label text.
Nantris
commented
1 year ago @nmay231 it doesn't seem to appear in the DOM at all. That's actually what got me back on this issue today.
I see a bunch of <div dir="ltr"></div> in the portal, and I assume at least one of them is for some given tooltip, but when I hover where tooltips should appear, not one of those DOM nodes changes at all on the problem machine. On all other machines, the DOM is modified as expected - which fits in line with my finding that the opened and _opened states don't ever evaluate to true on the problem machine.
@rtivital do any of the details under "Additional findings" in this comment give you any ideas for what I should investigate next?
rtivital
commented
1 year ago No, still no idea
reza-ebrahimi
commented
1 year ago I can confirm. None of the examples in the link below are working on the Linux Chrome browser.
https://mantine.dev/core/tooltip/
But they are working fine on Firefox.
nmay231
commented
1 year ago @Slapbox @reza-ebrahimi Would you provide a comment with this information, please? I don't exactly which would help, but we have to start somewhere.
<details>
<summary> Status: [[ affected/not affected ]] </summary>
[[ Some of the information below, you can find in the system settings application. Usually in "about" or something. ]]
CPU: [[ lscpu | grep name ]]
GPU: [[ lspci | grep VGA ]]
Linux: [[ lsb_release -d ]]
Windowing system: [[ Wayland/X11/etc. ]]
[[ Make sure to test the code sandbox: https://codesandbox.io/s/amazing-blackburn-ms245w?file=/src/App.tsx ]]
Chrome: [[ visit `chrome://version` ]]
Chromium: [[ if applicable, visit `chrome://version` ]]
Electron chromium backend: [[ if applicable ]]
If you are willing, cloned the latest version of Mantine and still have the issue with the storybook example: [[ not willing/yes issues/no issues (`yarn storybook`) ]]
</details>@nmay231
CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
GPU: Intel Corporation HD Graphics 530
Linux: Ubuntu 20.04.3 LTS
Windowing system: wayland
Chrome: 107.0.5304.87 (Official Build) (64-bit)
Chromium: N/A
Electron chromium backend: N/A
Sandbox code: https://codesandbox.io/s/amazing-blackburn-ms245w?file=/src/App.tsx
- Not working on chrome
- Working on FirefoxThanks for the organizational work @nmay231! I also think collecting the output of the Chromium GPU info page will be beneficial, based on another issue I dealt with in the past that seemed to be contingent upon GPU capabilities
That said - this issue affects our application even if we disable GPU rendering, so... I'm really not sure what the cause could be - especially since it's not just a rendering thing, but a problem with actually triggering the tooltip to appear at all (confirmed by DOM inspection.)
nmay231
commented
1 year ago @Slapbox My GPU info is listed in this comment.
GPU: VGA compatible controller: VMware SVGA II Adapter
Seems that you're running that in VMware. What are the host system OS and the windowing system (if applicable) if you don't mind me asking?
Nantris
commented
1 year ago @nmay231 host OS is Windows.
The problem appears to be related to Linux specifically, not necessarily VMWare. I think the VMWare adapter is just exhibiting whatever behavior the Intel Corporation HD Graphics 530 is also exhibiting - if that is indeed even related. For all I know, the GPUs are not the issue because the GPU should have no effect with --disable-gpu and it should also not affect whether or not onMouseOver fires.
I wonder if the issue affects other users with the same Intel graphic processor. If not, we could preliminarily rule out the GPU as a possible cause - though I wouldn't be sure where else to look at that point.
I guess really though, to completely rule it out as a cause we'd need each user to share the output of chrome://gpu - but like I said, --disable-gpu should fix the issue if it's the GPU - and it doesn't fix it.
Nantris
commented
1 year ago I know it's not much help, but I can confirm that the 4.2.12 is unaffected on the problem machine: https://codesandbox.io/s/hardcore-carlos-l62fk5
I changed the code in useTooltip.js and found that _opened is indeed always false on any problem machine.
const onChange = useCallback((_opened) => {
console.warn({ _opened }) // << Added console.warn
setUncontrolledOpened(_opened);
if (_opened) {
setCurrentId(uid);
}
}, [setCurrentId, uid]);What I noted: Every time the tooltip is hovered, nothing is printed. When the mouse leaves the tooltip target, then it prints {_opened: false}.
Tooltips can be made to appear on the problem machines: In the debugger, pause at this line and then call setUncontrolledOpened(true).
Nantris
commented
1 year ago @rtivital @nmay231 here's a sandbox using the example from Floating UI's tooltip page. It works on all machines, problem or not. I think there must be some implementation issue present in the Mantine configuration that isn't present in this minimal example: https://codesandbox.io/s/wizardly-wildflower-tl3bh0?file=/src/App.js
This is basically just a copy/paste of the code from https://floating-ui.com/docs/tooltip#usefloating-hook (but piecemeal because they don't have all of the relevant code shown in a single codeblock) - except I disabled the line whileElementsMounted: autoUpdate to be closer to Mantine's implementation.
With Mantine, when I set useFloating to rely directly on the outputs of useState (like below,) it didn't fix the problem, so I think there's some other issue in the Mantine code, which somehow is only affecting Linux. I wonder if this points to a problem in Tooltip.js or in use-tooltip.js, or elsewhere.
The floating-ui package in the repro is newer than in Mantine, but I forced Mantine to use the newest version in our project and it made no difference in the problem, so I don't think it has anything to do with Floating UI version.
function useTooltip(settings) {
const [uncontrolledOpened, setUncontrolledOpened] = useState(false);
// ...
const {
x,
y,
reference,
floating,
context,
refs,
update,
placement,
middlewareData: { arrow: { x: arrowX, y: arrowY } = {} }
} = useFloating({
placement: settings.position,
open: uncontrolledOpened, // <<< Updated to use useState instead of the useCallback
onOpenChange: setUncontrolledOpened, // <<< Updated to use useState instead of the useCallback
middleware: [
offset(settings.offset),
shift({ padding: 8 }),
flip(),
arrow({ element: settings.arrowRef }),
...settings.inline ? [inline()] : []
]
});
}So we can also rule out that it has anything to do with the useCallback here: https://github.com/mantinedev/mantine/blob/539c6c6e9f078467f7037d7314926c10b040b4c1/src/mantine-core/src/Tooltip/use-tooltip.ts#L44-L53
nmay231
commented
1 year ago @reza-ebrahimi Thanks for the info. Are you using a VM or WSL by chance?
@Slapbox At this point, I have no clue. Because I cannot reproduce it on any of my machines, I have no leads and no way to help.
My best advice to you is to set up a fresh local project (not in codesandbox so you avoid possible issues of iframes) install mantine and floating-ui in the same test project so they have the same peer dependencies, ensure there are no duplicate dependencies (yarn why @floating-ui/react-dom-interactions should say there is only one version installed). Make sure to use incognito mode. Vendor the entire Tooltip folder as a local component directory (or just vendor everything from mantine-core and not install it) and start tinkering from there.
The only other thing I can think of is that the order of some of the use* hooks passed to useInteractions is different, or something like that.
Best of luck.
reza-ebrahimi
commented
1 year ago @nmay231 No. It's just a pure Ubuntu install on hardware.
Nantris
commented
1 year ago Thanks for the tips @nmay231!
The only other thing I can think of is that the order of some of the
use*hooks passed touseInteractionsis different, or something like that.
@nmay231 that was not quite the issue, but a great lead! I think we're getting somewhere now!
From there, I started playing with this code and pared it down to the following, which worked!
const { getReferenceProps, getFloatingProps } = useInteractions([
useHover(context),
useFocus(context),
useRole(context),
useDismiss(context),
useDelayGroup(context, { id: uid })
]);From there I was able to determine that this line is the problem:
I don't know the implications of changing that line, or why it only affects particular Linux machines, but it is definitely the problem.
If anyone wants to investigate this - assuming that VMWare on any machine could produce the issue (which is an untested assumption) - you could try a ready-made Kubuntu image via VMDK file with VMWare Workstation Player
Nantris
commented
1 year ago @reza-ebrahimi what's your mouse situation on that machine?
Nantris
commented
1 year ago One more update today - sorry to create so many notifications.
A secondary issue I just discovered, is that the delay time is not honored on these machines after commenting out mouseOnly: !settings.events.touch
That appears to be caused by useHover's delay not being honored on these machines.
@reza-ebrahimi can you confirm that the delay doesn't work on your machine as well using this sandbox? https://codesandbox.io/s/awesome-lehmann-if4106?file=/src/App.js
Nantris
commented
1 year ago Just submitted a PR to @floating-ui/react-dom-interactions which should fix this: https://github.com/floating-ui/floating-ui/pull/2016
reza-ebrahimi
commented
1 year ago @Slapbox Thanks a lot for the investigation.
what's your mouse situation on that machine?
If you mean pointerType, Mine is hand.
can you confirm that the delay doesn't work on your machine as well using this sandbox?
- Most of the times there is a delay of 5 seconds.
- Sometimes after leaving the mouse pointer from Button, Tooltip disappears immidiately.
Nantris
commented
1 year ago Thanks for contributing to getting this resolved @reza-ebrahimi!
But eeeek, you're seeing a pointerType of hand?!
The only standard values are mouse, pen, and touch. I wonder what to make of the fact that yours is hand. @atomiks do you have any thoughts on that?
@reza-ebrahimi can you share the code you used to determine that value? And if it's definitely hand, can you share the contents of your /var/log/Xorg.0.log in a gist? I don't know that that will help, but I'm not sure what else to look at.
@rtivital there's a new version of @floating-ui/react-dom-interactions which would fix the issue for us and provides some more reliable fallback handling. If upgraded to 0.13.3 then the issue would be fixed for us (and presumably most of the limited set of users who experience this.) I tested this on my machine and it resolves the issue.
I'll keep working to get clarity on @reza-ebrahimi's machine and if/how that can be handled.
PS @reza-ebrahimi:
Sometimes after leaving the mouse pointer from Button, Tooltip disappears immidiately.
On my machine, this occurs when the windows isn't focused - but when the window is focused then the closed delay works and it won't disappear immediately. Is that the same on your machine.
atomiks
commented
1 year ago pointerType can be hand 😓 ?! Maintaining a library is hard, magical values can appear out of nowhere 😄
atomiks
commented
1 year ago @Slapbox I think the best way would be to convert your PR to just check for !== 'touch'. That will handle a myriad of cases we can't possibly predict, while removing hover for touch which is really the main goal.
Nantris
commented
1 year ago That was my initial thought, but I was hesitant since I didn't understand the intent and implications - especially since the naming is mouseOnly. Now that I have a better grasp, I agree with you. I'll wait a short bit to hear back from @reza-ebrahimi before moving forward with any changes.
But maybe it would be better to wait for whenever 0.14.0 would land and to rename mouseOnly to a more appropriate name like disableTouch or something like that? I would have probably suggested !== 'touch off the bat, except the naming led me to believe that might be a bad idea. What do you think @atomiks?
atomiks
commented
1 year ago Yeah I do think it needs to be renamed as a result. I try to keep breaking changes to a minimum, but sometimes unavoidable :\
reza-ebrahimi
commented
1 year ago @Slapbox
But eeeek, you're seeing a pointerType of hand?!
The only standard values are mouse, pen, and touch. I wonder what to make of the fact that yours is hand. @atomiks do you have any thoughts on that?
can you share the code you used to determine that value?
Maybe there is a confusion here, the question was what's your mouse situation on that machine? and I just checked the link below to see the mouse cursor on buttons. For mine it is hand. Now I think my answer could be wrong.
https://mantine.dev/core/tooltip/
Let me know what I need to do for this to provide you with a correct answer :)
On my machine, this occurs when the windows isn't focused - but when the window is focused then the closed delay works and it won't disappear immediately. Is that the same on your machine.
I used the link below to test it. I tested it again and the delay is happening almost all the time.
https://codesandbox.io/s/awesome-lehmann-if4106?file=/src/App.js
atomiks
commented
1 year ago Yeah we're not referring to cursor: pointer CSS, we're referring to the value you see onPointerEnter(event) of event.pointerType. If you upgrade to 0.13.3 in that Sandbox, you should see it 100% of the time not "almost", if the problem was the same as @Slapbox's.
Here's a Sandbox to see, what does the console say? https://codesandbox.io/s/great-rain-6rjgil?file=/src/App.js
reza-ebrahimi
commented
1 year ago eah we're not referring to cursor: pointer CSS, we're referring to the value you see onPointerEnter(event) of event.pointerType. If you upgrade to 0.13.3 in that Sandbox, you should see it 100% of the time not "almost".
Now I can say the reason behind "almost" wording. The reason is, when mouse pointer goes on the button and leaves it (before reaching to 5 second timeout), and doing that again (actually two times enter and leave before 5 second timeout), the tooltip disappears immediately on the second leave.
But with one time enter and leave the delay happens 100% of the time.
Here's a Sandbox to see, what does the console say?
pen
atomiks
commented
1 year ago The reason is, when mouse pointer goes on the button and leaves it (before reaching to 5 second timeout), and doing that again (actually two times enter and leave before 5 second timeout), the tooltip disappears immediately on the second leave.
Does this happen on my Sandbox (upgraded to 0.13.3)?
pen
Ok good, we've corrected this already in 0.13.3, so the issue should be fixed without needing anything else changed
reza-ebrahimi
commented
1 year ago Does this happen on my Sandbox (upgraded to 0.13.3)?
With this sandbox (https://codesandbox.io/s/great-rain-6rjgil?file=/src/App.js):
we've corrected this already in 0.13.3, so the issue should be fixed without needing anything else changed
That's great. Thanks a lot!
nmay231
commented
1 year ago Ok good, we've corrected this already in 0.13.3, so the issue should be fixed without needing anything else changed
So we just need a PR upgrading @floating-ui/react-dom-interactions to resolve the issue on Mantine's side?
atomiks
commented
1 year ago Yes, I also changed the package name just then to @floating-ui/react (for a couple reasons) but it has the fixes in. It should be straightforward to upgrade to that package in Mantine
Nantris
commented
1 year ago Thanks very much for all your hard work @atomiks and sorry to increase the load on your end!
@nmay231 @rtivital can we get a plan for when this package version bump should be done in Mantine? I'm hoping it could be done in the next minor release (assuming there will be a 5.10) Are there any implications to bumping the version that I'm not considering?
rtivital
commented
1 year ago There should not be any issues, I'll update the package to the latest version in 5.10
picobyte
commented
1 year ago A bit late to confirm, but I seem to have the same issue: boxes instead of icons. Chromium Version 115.0.5790.170 (Official Build) Arch Linux (64-bit)
Nantris
commented
1 year ago @picobyte that doesn't sound like the same issue, and I apologize for not properly updating the title and closing this. I do believe this is resolved via an upgrade of the floating-ui dependency.
In my case it was not Linux per se, but the fact that pointerType was pointer rather than mouse. In my case nothing showed, but it sounds like something is showing for you.
I'd advise opening a new issue, or otherwise updating the details here to show that this issue isn't fixed. I will close this issue for now (as I should have long ago) because I believe this is fixed.
picobyte
commented
1 year ago Well Slapbox, you've helped me a lot because it was exactly the issue it seems. I just had to run npm install @floating-ui/dom and restart chromium, and now the icons are there.
What package has an issue
@mantine/core
Describe the bug
At least on the machines I have available to test with, uncontrolled tooltips generally will not appear at all - but rarely will appear for the first hover and then never again. Affects X11 and Wayland.
First discovered this on
5.2.7.What version of @mantine/hooks page do you have in package.json?
5.4.1
If possible, please include a link to a codesandbox with the reproduced problem
https://codesandbox.io/s/amazing-blackburn-ms245w?file=/src/App.tsx
To reproduce: Hover the text "hello" with a Chromium browser on a Linux machine - no tooltip will appear
Issue occurs on: Ubuntu 22.04 and Linux Mint 20.2 Works properly on: Windows 7 and macOS 12.4
Do you know how to fix the issue
No
Are you willing to participate in fixing this issue and create a pull request with the fix
Yes
Possible fix
Unknown