Fine-tune delays in Tooltip and associated components

[r100-stack]

Note

Merging this PR in the next minor release (#2368 (comment)).

Changes

After we fixed the default Tooltip delay in #2263, a couple of components had the problem of lingering tooltips. To fix it, this PR wraps some of the parts of the affected components within Floating UI's FloatingDelayGroup.

Components where FloatingDelayGroup wrapper is added:

• SideNavigation
• Slider
• Stepper
• List (#2368 (review))

While this PR fixes the lingering tooltip problem within the items of the component itself, it doesn't fix the problem between two components. To fix the latter part also, I had considered moving FloatingDelayGroup to the ThemeProvider but then didn't go that route based on our internal discussion. One of the reasons to not go that route was to prevent unintended issues.

According to our discussion, I also changed the default tooltip delay from { open: 50, close: 250 } to { open: 100, close: 200 }. If we later find research regarding the best delay values, we can further fine-tune this default delay.

Testing

CI passing after small updates to the tests.

Before and After

Component	Before	After
Stepper	Before.mov	After.mov
SideNavigation	Before.mov	After.mov
Slider	Before.mov	After.mov

Docs

Added a changeset.

After PR TODOs:

• See how to solve lingering tooltips across different components. (#2368 (review))
• Document more about the placement of the Tooltip (#2368 (review))

[smmr-dn]

I also notice the problem caused by delay when the label prop is passed into IconButton. Does it still need to be wrapped with FloatingDelayGroup?

tooltip-delay-in-menu.mp4

[r100-stack]

I also notice the problem caused by delay when the label prop is passed into IconButton. Does it still need to be wrapped with FloatingDelayGroup?
tooltip-delay-in-menu.mp4

Since those Tooltips are across different instances of IconButtons, this PR doesn't address that atm. While putting FloatingDelayGroup into something global like the ThemeProvider will fix the issue, it might lead to other issues which is why this PR went away from that approach (more info in the PR description). Instead, this PR just solves the lingering Tooltips issues within an instance of a component and not across different instances of same or different components.

Also, noticed an issue in the example where the text parts of the ListItems were not visible. Fixed that in b9b2d1c.

Screenshots

Old	New

[mayank99]

I also notice the problem caused by delay when the label prop is passed into IconButton. Does it still need to be wrapped with FloatingDelayGroup?

Since those Tooltips are across different instances of IconButtons, this PR doesn't address that atm.

Could we use FloatingDelayGroup in List? It makes sense because it is an isolated component containing repeated items (similar to SideNavigation/Stepper/ButtonGroup/etc).

[r100-stack]

I also notice the problem caused by delay when the label prop is passed into IconButton. Does it still need to be wrapped with FloatingDelayGroup?

Since those Tooltips are across different instances of IconButtons, this PR doesn't address that atm.

Could we use FloatingDelayGroup in List? It makes sense because it is an isolated component containing repeated items (similar to SideNavigation/Stepper/ButtonGroup/etc).

Makes sense, wrapped List with a FloatingDelayGroup (c889805). In that example, it helps when users are quickly hovering from one more options icon button to another in a top to bottom way. But when going from bottom to top, there's not much improvement. Also, the top to bottom way is improved only in the case where the user is hovering quickly. With a regular hover speed, there is actually little difference with or without the FloatingDelayGroup.

However, added the FloatingDelayGroup as it is at least an improvement.

Screen-recording

Without FloatingDelayGroup	With FloatingDelayGroup
Without.mov	With.mov

[mayank99]

But when going from bottom to top, there's not much improvement.

One fix for that would be to change the tooltip's placement, which consumers can do on their own.

I think this is quite a common issue for lists, and we should probably recommend changing placement in our documentation somewhere.

[mayank99]

LGTM

[r100-stack]

But when going from bottom to top, there's not much improvement.

One fix for that would be to change the tooltip's placement, which consumers can do on their own.

I think this is quite a common issue for lists, and we should probably recommend changing placement in our documentation somewhere.

Sounds good, added the documentation part as an after-PR TODO since I saw your approval.