Describe the bug
When using the ColorPicker, the tooltip doesn't disappear unless the user clicks somewhere else that takes focus. This causes the tooltip to overlay itself when scrolling. This can be seen pretty easily in the Control Gallery Sample.
Steps to reproduce the bug
A similar issue appears if you later also give ColorPicker focus again and then scroll, as it seems whenever ColorPicker has focus it displays the Tooltip.
Expected behavior
The tooltip should disappear after a short time after the user has finished manipulating the selection.
Version Info
Controls Gallery Package
| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2020 Update (19041) | Yes |
| November 2019 Update (18363) | |
| May 2019 Update (18362) | |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) | |
| Device form factor | Saw the problem? |
| :----------------- | :--------------- |
| Desktop | Yes |
| Xbox | |
| Surface Hub | |
| IoT | |
@kikisaints I think we could probably do something with effectiveViewPortChanged to fix this but some thought would need to go into the desired behavior.
@StephenLPeters What speaks against collapsing the tooltip as soon as the user starts scrolling? The tooltip wouldn't be aligned with the "actual" color picker (the circle users can drag around the color panel to select a color) any longer and it rapidly starts to look visually unpleasing.
I think the options are either close the tip or move it with the color spectrum. you are right we wouldn't want it to be misaligned (as it is currently). And if we decide to move there are questions around what to do when it scrolls off screen and stuff like that.
I think closing the tooltip makes more sense, otherwise we would need to check when the colorspectrum is actually visible on screen and didn't get occluded by something else as part of scrolling.
My suggestion is that the tooltip should be
If we only show the ToolTip for a few seconds anyway (if not currently being dragged) then we don't really have to take care of preserving the tooltip when scrolling. If the user scrolls away from the color picker, they are moving their focus elsewhere so we can close the tooltip just fine. Any additional inconveniences caused by it not disappearing "fast enough" when the user scrolls reasonably fast would thus be eliminated.
I think closing the tooltip makes more sense, otherwise we would need to check when the colorspectrum is actually visible on screen and didn't get occluded by something else as part of scrolling.
EffectiveViewportChanged lets us do just that though
That's true yes. Should we follow the TeachingTip behavior in this case? A persistent ToolTip like in this case seems is quite similar to a TeachingTip in this regard.
I implemented my suggestion outlined above in WinUI for better visualization:
The tooltip got a default show duration time of 5 seconds (meant to match UWP's default tooltip duration time). Changing the position of the circle either by mouse/touch or keyboard will show the tooltip and the tooltip will be hidden if no movement change has been registered for 5 seconds.
When the user scrolls, the tooltip is hidden. As written above, since we should hide the tooltip anyway if no change happens after some time, there is little reason for us to preserve the tooltip when the user scrolls. A scrolling user is most likely directing their focus away from the color picker (if they interacted with it prior to the scrolling) and thus the overlay nature of the tooltip will cause visual inconveniences if the user scrolls reasonably fast. As the tooltip would disappear after five seconds anyway (since the user is now likely interacting with other UI elements after their scrolling) we prevent the visual inconveniences by hiding it directly.
(The current behavior of showing the tooltip on focus received and hiding it on focus lost remains unchanged.)
Honestly, I think this is looking quite good (minus the visual quality of the color spectrum in the gif).
@michael-hawker @StephenLPeters @chingucoding What do you think?
@StephenLPeters Your thoughts on the suggestion above (see the GIF)?
@StephenLPeters Friendly ping.
@Felix-Dev looks good to me as the OP. 🦙❤