Mozilla tooltips have the WS_EX_TOPMOST style but real Windows tooltops don't. Steps to reproduce problem: 1. Start System Monitor or other program with an "Always On Top" settings 2. Start mozilla -console 3. Move System Monitor over where Mozilla's tooltip will display 4. Hover over Mozilla to display a tooltip 5. Move System Monitor over where Windows' tooltip will display 6. Hover over Mozilla's console's toolbar's buttons to display a tooltip Actual result: Mozilla's tooltips display over System Monitor Expected result: Windows' tooltips display under System Monitor Additional information: If Mozilla starts performing a long operation (e.g. loading a summary file) neither it is possible to dismiss the tooltip nor does it disappear when tasks are switched.
adding self to cc: list
I'm seeing this, too. This raises another issue, being that tooltips and mouseover effects shouldn't be active when the application isn't active. But that's another day... Looks like the offensive -- er... offending code is here: http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#3440
(My apologies to Neil, who already quoted the exact same line in lxr as the URL for this bug.)
Reassigning from bdonohoe to hangas
Clearly a bug, not a UI design issue. This needs fixing on Windows, at any rate. It's also a problem on Mac (build 2000082608, Mac OS 9.0), though with considerable precedent: with both 4.x and Office 98 on Mac (the only apps I can find with tooltips, as opposed to help balloons), the tooltips don't succeed in being topmost either. To reproduce: tear off the application switcher from the menu bar, and place it over where the tooltip is going to appear. If the tooltip appears under the application switcher, the wrong thing has happened. John, can you try this on Linux? Does X have always-on-top-style windows at all?
Waitasec, Matt. Are you saying that on the Mac, the tooltip should appear _above_ the app switcher? If so, that's the exact opposite of the desired behavior on Windows, and the original bug description.
Oh. Ok, I didn't read the bug properly. I'm sorry. So, you're saying that tooltips shouldn't appear topmost, and the fact that they do in Mozilla on Windows is a bug in Mozilla. And I'm saying that tooltips should always appear topmost (assuming a fix for the other bug you described), and the fact that they don't in native tooltips on Windows is a bug in Windows. Hmmm. Well, not as clear-cut as I thought, then, is it? Back to Hangas for a UI decision.
I don't think that's a bug in windows. Nowhere is it indicated that anything Mozilla does will be in a topmost window. So if I have Task Manager, WinZip, or whatever set to be on top of everything else, it will be pretty weird to have tooltips showing through from an application that's underneath said topmost window.
Just to answer mpt's question: I can't recall using an X app that had 'always on top' behaviour, as in 'above any other app'. Certainly, a given window of an app can be set above other windows of that app, but not 'system' wide. (It's technically possible, but generally not done).
(Oh sure, as per usual Microsoft had to go and mess with this in Office 2000. Now tooltips display on top of top-most windows. I don't like that, personally.)
Ok, so tooltips come right to the top in Office 2000. Microsoft UI conventions tend to be introduced in IE, propagate to Office, and then to Windows itself. So, can anyone test what happens to tooltips in * IE 5.5 * Windows 2000 * Windows ME? (I'll try all three at the cafe tomorrow, if no-one else has by then.) If tooltips in at least two of those three come right to the top, I think we will have found a new Microsoft UI convention which we should be following (both because we can assume it's going to become standard behavior, and because it's got greater usability).
IE 5.5 - tooltips remain underneath the Task Manager. I'll try 2000 once I get to work. Someone else will have to do Me. (Gee, that sounded kind of odd)
Win2000 - ditto. Looks like Office 2000 is the odd man out here.
Sending to XP apps.
Getting tired, I meant Toolkit/Widgets.
-> future, no time in the current cycle
accepting for future
See related (but not dupe) bug 131131.
*** Bug 222011 has been marked as a duplicate of this bug. ***