Tooltip Should Not Trigger on Click

[simon.ferndriger]

Neither the standard Windows tooltip, nor the Google tooltip, nor the tooltips on this very page (Github*) trigger on click.
Now, the jQuery tooltip DOES still show on/after click, I assume this is because it triggers also on focus which is (in most cases) generated by a click.

However, the tooltip helps decide whether or not to click somewhere. When the element is clicked, this decision has already been made. Therefore, the tooltip is not needed anymore. I understand, that it is desirable to show the tooltip on FOCUS when using tab navigation, however, this also means that the tooltip is still shown on CLICK - which is never desirable and also produces an unsolvable bug: ​http://bugs.jqueryui.com/ticket/9336.

So I suggest to either give the option to disable showing the tooltip on FOCUS in general, or work out a solution (as Google did it) to show the tooltip on FOCUS, but NOT on CLICK.

---

Please consider this for your next release. Thank you.

*) It is interesting to see, that the tooltips on the right do NOT show on FOCUS, probably because these links keep FOCUS due to the tab navigation. So an active/clicked tab would demonstrate this problem perfectly by probably still showing the tooltip when active...

[Scott González]

The tooltip doesn't care about clicks at all. It is shown on *focus*, as documented in the ​ARIA Authoring Practices.

Given that information, the change as requested doesn't make any sense, since there's no change to make. Presumably, what you want is that tooltips *close* on click, since they're already open due to the link receiving focus. However, this can't even be applied generically. For example, would you want an input's tooltip to close because you clicked into it to give it focus?

Anyway, the case you've described originally wouldn't change here. This is what would happen:

1. You mouse down on the anchor, giving it focus, and the tooltip opens.
2. You release the mouse button, resulting in a click. The tooltip would close due to a click.
3. The browser would follow the link, causing the current document, and therefore the anchor, to lose focus.
4. You return to the original page, the document and anchor regain focus. The tooltip opens.

See how you'd get the exact same behavior as today? Closing on click does nothing because it happens at exactly the same time as the anchor losing focus anyway, due to the window being backgrounded. Upon returning to the page, the anchor is still going to have focus and therefore will receive a focus event again, resulting in the tooltip being shown again.

[simon.ferndriger]

Tooltip on inuput Yes, this is a good example where you want to keep the tooltip open on focus.

Close tooltip on click OK, closing on click does not help per se. The tooltip would need some memory in order to achieve a desirable result. It was just a wish for the end result (being/staying closed on click), not the solution for it.

However, it would still be desirable to opt out the focus trigger for (some) tooltip applications - like it is also the case on Github for the icons on the right hand side.

[Scott González]

I'm not sure what you're referring to when you say "Google tooltip." Google's ​Material Design specification says that tooltips should appear on focus. Gmail, which doesn't use Material Design yet, also has tooltips that appear on focus. The tooltips close based on certain mouse movements, though. However, even when closed, if you make the window inactive (such as switching tabs or applications), then return to the window, the tooltip will reappear (because it receives focus again). The tooltip does close on mousedown though (for a button, I didn't see an input with a tooltip to test).

[Scott González]

It's also worth noting that while the GitHub tooltips don't handle focus, they do not close on click.

[simon.ferndriger]

I see that this subject has a much bigger scope than I thought at first. Maybe its better to just use the workaround for the moment and see where the Material Design is going to in the near future.

[Scott González]

Based on all of the information that has presented, the team has decided no changes should be made.

Setting to wontfix since this was filed as a feature, but really I'd say this is notabug.

[simon.ferndriger]

Sure, I agree.