There should be no delay when hovering over another icon after having hovered over an icon to show a tooltip in the NavigationView

[Poopooracoocoo]

Describe the bug

There should be no delay when hovering over another icon after having hovered over an icon to show a tooltip in the compact NavigationView and in various other places

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Open XAML Controls Gallery
2. Click on Close Navigation or resize the window to get the Navigation to be compact
3. Hover over What's New until the tooltip appears
4. Move cursor to All controls

Expected behavior

There is no delay upon switching between the two.

Screenshots

Version Info

NuGet package version:

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)
Anniversary Update (14393)

Device form factor	Saw the problem?
Desktop	Yes
Mobile
Xbox
Surface Hub
IoT

Additional context

This happens on Chromium/Chrome/Anaheim tabs as well as on the wifi and volume icons in the taskbar.

[jevansaks]

This would be a new feature for tooltip in XAML and unfortunately since this isn't a universally supported Windows-ism I don't see this being something we would change. Sorry!

[Poopooracoocoo]

@jevansaks what does universal mean? Davinci Resolve which uses custom tooltips implemented this. Should I record it and add it to the issue? In controls like NavigationView, this would make things faster and make it more like win32.

[jevansaks]

what does universal mean?

@poopooracoocoo I meant that unlike other interactions for windows I don't see this working everywhere that tooltips appear. It works in the Windows explorer system tray icons, but not in the taskbar tiles or between the language switching button, clock or action center buttons.

It's something we could do, but the reason I closed it is that given infinite time I don't see this being a high priority for us.

That said, if you have a proposal for the code changes to fix this either in NavigationView or in the XAML framework (once the relevant part is open-source'd), I'd be happy to discuss that.

[Poopooracoocoo]

I don't why it only works in the system tray icons. :/ To add to the inconsistency, it doesn't happen in the ribbon of File Explorer but it does happen in the status bar's view icons.

It's something we could do, but the reason I closed it is that given infinite time I don't see this being a high priority for us.

@jevansaks Well it could be open. Other people won't see this issue when it's closed.

[jevansaks]

@jevansaks Well it could be open. Other people won't see this issue when it's closed.

Sure, i can leave it open in the backlog.

[YuliKl]

@Poopooracoocoo, do you think #1103 would solve the problem that this issue is tracking?

[Poopooracoocoo]

@YuliKl It's not really the same.

[Poopooracoocoo]

I just noticed that Microsoft Whiteboard has this!

btw I don't like #1103 personally. I also dislike Whiteboard in all honesty. It's slow and I have to sign in to use it. It was supposed to replace Sketchpad. I don't really need syncing. I really just use it for maths and stuff

[marcelwgn]

@Poopooracoocoo Is the following behavior fine with you, or is this to much delay between hiding the old tooltip and showing the new tooltip?

[Felix-Dev]

This would also make sense for the TabView control (especially for tabs hosted in compact mode). Would, in my view, improve the user experience in a noticeable way and would also match Edgium's behavior (and Edge UWP's). Will open an issue for that soon.

[Poopooracoocoo]

@chingucoding It looks like there's too much of a delay. Ideally there'd only be an animation for the first tooltip and then there wouldn't be anymore (or faster) animations until the last tooltip with an exit animation. Here's what I mean:

[marcelwgn]

Thanks for the clarification @Poopooracoocoo !

[marcelwgn]

Here is a quick proof of concept using buttons

@ranjeshj @YuliKl @anawishnoff From a technical perspective, this is definitely possible to implement, what are your thoughts on this feature wise? @stmoy What do you think about adding this to TabView like @Felix-Dev proposed?

[AzAgarampur]

Just an idea: Can we remove the rounded corners from the WinUI tooltips? I feel like they would match the rest of the win32 tooltips and with a quick popup animation, they would appear pretty neat.

Also, removing the border padding would be nice.

[ranjeshj]

If we are talking about updating tooltip code, I believe that would be in the framework codebase so we will need to do it post WinUI3.

[marcelwgn]

I was thinking about adding some code NavigationView and NavigationViewItem here. The problem here is that this of course won't make NavigationView faster. My idea is to just add this to NavigationView and possibly to TabView if @stmoy approves that. We won't need to touch ToolTip code for those two scenarios.

[ranjeshj]

@stmoy, @anawishnoff and @YuliKl can comment for the individual controls. The issue I see is that tooltips will start popping up faster in some places but not in others which might be weird.

[anawishnoff]

Yeah, this is a hard one because I think this goes back to Jevan's original comment about how this behavior would have to be universal, and it's hard to conclude that it would the right behavior universally. So, as Ranjesh said, it might feel a little odd to have this on NavigationView or TabView but nothing else. I'd like to hear other opinions on this though, as I do think this would be a nice thing to have in TabView.

[Felix-Dev]

@anawishnoff I checked Edgium some more and the tooltips of its side-by-side TabView buttons (such as back/forward/refresh button) have the "standard" tooltip show delay. I bring that up because users are already familiar with UI where in some select places - like Edgium's tabs - the tooltips are shown without delay and in the rest of the places inside the same app a tooltip show delay is used. It's not like users now start expecting that controls like the NumberBox will show its SpinButtons tooltips without a delay in between (the SpinButtons currently don't have show tooltips but this is planned to my understanding).

Plus, there is noticeable user benefit in compact UI like TabView or NavigationView showing tooltips without delay in between.

Taking these two points together, I would like to see this being implemented for controls like the TabView and the NavigationView.

Let's make use of the existing familiarity of this feature for users (via Edgium,...) and apply it in WinUI as well where it makes sense and won't be unexpected for the user. The TabView and NavigationView are two controls this applies to, in my opinion.

[stmoy]

In the context of TabView, I think this makes sense. The ToolTips in TabView often host important secondary content (such as the header text on a webpage) in addition to the name of the tab - being able to quickly see this content is worthwhile. I'd imagine a similar justification could be used for NavigationView as well.

[YuliKl]

What about showing tooltips on keyboard focus? Would you expect that delay to also be removed or remain as is?

[marcelwgn]

This would match the current edgium behavior.

[Felix-Dev]

@YuliKl Is there a reason why we should treat keyboard focus (i.e. "tabbing" through the different tabs instead of moving the mouse) differently here?

Edgium, for example, makes no difference with its tab hover cadrs between keyboard navigation or mouse movement:

[YuliKl]

Just posing the question :) Because a keyboard user has to travel through contiguous items, unlike a mouse user who can move the mouse away from the items, I wondered if the flashing tooltips might get annoying with keyboard. After all, the delay before showing a tooltip had been added on purpose.

[Poopooracoocoo]

What about showing tooltips on keyboard focus? Would you expect that delay to also be removed or remain as is?

win32 tooltips (at least in the system tray in the taskbar) have a delay with keyboards. I rarely use my keyboard as my main navigation tool but I imagine that waiting would get annoying.

After all, the delay before showing a tooltip had been added on purpose.

@YuliKl Are you referring to the initial delay of a "set" of items?

And with Edgium you can't really repro it with the Aura tooltips as you have to focus on the close button. (speaking of which, chromium has a nasty bug to do with tooltips and touchscreens...) Another one I can see right now is the native tooltips on the window caption buttons. The CommandBar control could do with this behaviour. It looks like ribbons don't have this.

Y'all should look at which controls in other UI frameworks have this tooltip behaviour. Some websites that have custom tooltips, like Gmail, have this. I wonder if the peeps who worked on the other UI frameworks at MS have had conversations like this too.

[Poopooracoocoo]

If Age of Empires III DE, a game, can do this, surely Microsoft's 'primary' native user interface for their own OS should.

[Poopooracoocoo]

Also see https://react.fluentui.dev/?path=/docs/preview-components-toolbar--default#with-tooltip

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Poopooracoocoo]

Do not close