Tooltip Bugfix After 22 Years

[RealityRipple]

bug #148624 got fixed with a single "doc->HasFocus" call. Now begins the huge debate as to whether non-focused applications should show tooltips.

[Moonchild]

Now begins the huge debate as to whether non-focused applications should show tooltips.

*crickets*

[moonbat]

A tooltip by definition exists to show a little more detail about the UI element visible below the mouse pointer; if there isn't one due to being covered up by another window, it makes no sense to be shown and will only confuse the slower witted majority.

[Nuck-TH]

A tooltip by definition exists to show a little more detail about the UI element visible below the mouse pointer; if there isn't one due to being covered up by another window, it makes no sense to be shown and will only confuse the slower witted majority.

Out of focus absolutely doesn't mean that window is obscured by another one.

Well, windows itself inconsistent about it. Take explorer for example - inside unfocused window tooltips doesn't show, but they do on titlebar buttons. Symbol table shows tooltips always. Some other system applications behave like explorer.

[Moonchild]

Take explorer for example - inside unfocused window tooltips doesn't show, but they do on titlebar buttons.

I never understood why titlebar buttons have to have captions anyway (if their function is not clear, then you're having bigger issues...), let alone on background windows. But one could argue that window frames are system elements and since your desktop environment is always focused when you're using it, it would make sense in that case. Application content is different from its window -- Linux actually makes a much clearer point of that.

if there isn't one due to being covered up by another window

This may or may not be the case, but to be accurate in that case you'd have to keep track of every window inside every application to know if a mouse position is actually over THIS application or covered up. The simple and I think logical solution is to not show them for non-active windows (unless you are using an auto-raise alike behaviour in your system, shifting focus based on mouse position, but even then, you can just go by the focus...)

[Kris_88]

Logically the rule is simple. If you can click on a button and it will perform an action, you will also be able to see a tooltip. If the tooltip is not displayed due to focus on another window, then clicking should not work either. At the same time, simply hovering the mouse over a button should not change focus.

[Moonchild]

Logically the rule is simple.

If the tooltip is not displayed due to focus on another window, then clicking should not work either.

That rule doesn't work when you're dealing with cascading windows. When you click, you transfer the focus to the previously background application to perform the click action. a hover action doesn't do that, as you yourself say. So you can't apply this rule as it's paradoxical in that context. If you want to apply that rule then you have to fundamentally change how focus-shifting works (i.e. requiring a click to change focus without performing any action). What would confuse the user more: a tooltip not displaying on a control that is in an application that doesn't have focus, OR their "clicking doing nothing"? something something cake something eating.

[Kris_88]

What would confuse the user more: a tooltip not displaying on a control that is in an application that doesn't have focus, OR their "clicking doing nothing"?

I'm just saying that the ability to perform an action on a click (with automatic focus change if necessary) and displaying a tooltip are related things. I can click on a button in an inactive window and know that the focus will change and the action will be performed (I don’t even always notice that the window is inactive). Nobody doubts this. Since this is so, the tooltip should work in an inactive window, because it is needed to explain the action that will be performed when clicked. Since the click will work, the tooltip should also work.

[athenian200]

Off-topic:
In case anyone was wondering, I checked and we apparently have this fix already:

https://repo.palemoon.org/MoonchildProd ... 607daa7966

[Moonchild]

Since this is so, the tooltip should work in an inactive window, because it is needed to explain the action that will be performed when clicked.

As already explained it's not practical to do this in a way that would be technically sane, and the result otherwise would be the obvious problem with disembodied tooltips showing over applications that they don't belong to, which is the bug that's been fixed with this.
If you want the additional optional help, activate the window.

[Moonchild]

Off-topic:
In case anyone was wondering, I checked and we apparently have this fix already:

https://repo.palemoon.org/MoonchildProd ... 607daa7966

correct, it will be in the upcoming release.

[Kris_88]

If you want the additional optional help, activate the window.

Sometimes it is not obvious that a window is not active. And the lack of a tooltip is annoying.
And, of course, tooltips are needed for new applications that I am not very familiar with. Therefore, I personally don’t care how tooltips will work in Pale Moon. But logic, Moonchild, it's all about logic...

U1.png