(*** This bug was imported into bugs.kde.org ***) Package: kicker Version: KDE 3.0.1 Severity: normal Installed from: Compiled From Sources Compiler: gcc 2.95 OS: Linux OS/Compiler notes: Not Specified When moving the mouse over buttons on the Kicker panel sometimes the tooltips don't go away when the mouse is moved off the button. I have button zooming turned off if that makes a difference. I have been able to reproduce it reliably using the following method: 1. Move the mouse onto a button and wait for the tooltip. 2. Now slowly move the mouse pixel by pixel towards the edge of the panel. 3. The tooltip should disappear just before the mouse reaches the edge of the panel and the button should no longer be highlighted BUT don't stop -- continue moving the mouse slowly towards the edge of the panel. 4. As the mouse crosses the edge of the panel the tooltip reappears "attached" to the edge of the panel and stays there even if you move the mouse all the way out onto the desktop. The tooltip only disappears if you mouse back over the same button in the Kicker panel. It seems that this occurs in normal mouse movement when the mouse happens to hit that very small spot along the edge of the panel that triggers the sticky tooltip. (Submitted via bugs.kde.org)
Created attachment 299 [details] Konqueror tooltip persists despite mouse having long left the toolbar It appears that when this bug occurs the tooltip stay either 'stuck' to the toolbar or at a constant distance of about 1/3 of a centimetre.
I have also noticed this bug, I have found another quite reliable way to reproduce the bug is to quite slowly move the cursor down the screen until it just rolls over the edge of the taskbar button, as soon as the tooltip appears, go back to the program window (making sure the cursor doesn't roll over the tooltip as that will make it dissappear). The tooltip will stay either 'stuck' to the task bar or about a 3rd of a centimetre above it (I have attached screenshot of tooltip in the 2nd position). from my observations the bug seems to only occur when the tooltip is entirely in the program window rather than in or partly in the taskbar area, (although this may just be due to my method of reproducing the bug).
*** Bug 51237 has been marked as a duplicate of this bug. ***
Stumbled accross this bug too. I'm using KDE 3.1 on FreeBSD 5. The bug seems partially fixed insofar as moving the mouse over any button in the kicker makes the tooltip disappear, however the bug can still be produced as follows: 1. Have the kicker at the bottom screen border 2. Create a tooltip my hovering the mouse pointer over any (kind of) button in the kicker. The button must be directly adjacent to the bottom screen border. 3. Move your mouse to the bottom screen border 4. Leave the kicker area either by moving the mouse along the screen border (you must not cross any of the "hide kicker" buttons), or by moving the mouse cursor through empty space in the taskbutton area. I get "empty space" by having two taskbar button rows, and having them not fill the available width.
*** Bug 55298 has been marked as a duplicate of this bug. ***
Using ArkLinux alpha 7 with KDE 3.1.1 -1 week. It seems to me that the tooltip bug is triggered by some kind of button press area extension (for improved usability) or however to call that. For visualizing this just do following: First of all disable icon zooming. Move your pointer onto any button icon in the kicker, the icon will highlight and the pointer is shown as hand, and after some time a tooltip will appear. Now slowly move the pointer to the edge of the kicker, near the edge the highlight will disappear and the tooltip re-popups at a new location. Now exactly those tooltips are the ones which stay. It seems to me that the area around the actual button is too thin (2 or 3 pixels) to first trigger the popup of the tooltip and then make it disappear again.
Created attachment 1289 [details] Patch vs. kicker source 3.0.0 This patch fixes the problem for me. More of a workaround than a real fix though...
Created attachment 1297 [details] patch for qt/src/widgets and kdebase/kicker/core Could you please try to reproduce the problem with these attached patches for Qt and Kicker? They're fixes for some other problems I have, but I cannot reproduce this problem with them, so it's possible they fix this problem too.
Hi Lubos, I applied your patch (id=1297) to the HEAD revision of qt-copy and kdebase and rebuilt but unfortunately the problem is still around.
The patch by kdozer (id=1289) works for me (using the HEAD revision). Can someone with more knowledge than me please comment on it?
cmueller: My patch just adds a check for QEvent::Leave in the eventfilter and forces all panel tooltips to be hidden at this point. Of course, this should not be necessary so it's a workaround rather than a fix.Can't see any harm in it though, if no real solution can be found. Can the maintainer comment? Maybe the real issue is related to the eventfilter for QEvent::Enter which fakes an XFocusIn event. I use the following to reproduce the bug. This works for applets/application buttons/systray icons etc. I am using KDE 3.1.1 and QT 3.1.2 I am using Click-to-focus with Large Panel and no kicker auto-hiding, althogh the problem seems to exist with all focus policies/kicker sizes. 1. Place An editor window behind the kicker (Kicker set to stay on top) 2. Hover over anything in the kicker (near the top edge - assuming horizontal lower Panel) 3. Wait for tooltip to appear 4. Very slowly move the pointer up to the edge of the panel 5. When we are over the last pixel of the panel, the tooltip disappears 6. Once we go another pixel, leaving the panel, the tooltip reappears. 7. When we go a couple more pixels the pointer changes to the carat for the editor window. 7. Tooltip stays until we return the panel (actually, it disappears after ~10sec) It seems like there is some invisible border around the panel where it looks like we are outside, but the focus doesn't change to the current window (or Desktop). A general problem with QTooltips seems to be that once one appears for one widget, moving to another widget in the same app makes the tooltip appear immediately instead of waiting for a hover. (e.g. try moving between toolbar buttons in Konqueror). If this were fixed in QT, then this problem in kicker would probably disappear.
Same problem here, Above instructions do reproduce it for me. This also happens to me sometimes with the window decoration buttons. I sometimes get a "Close" tooltip stuck on the screen. ~Mike
I'm affected by this bug too. (KDE CVS HEAD from yesterday). I know and hate this bug since KDE 3.0. And for me it just happens with kicker. No other tooltips show this behaviour. Steps to reliably reproduce it for me: 1. Panel at bottom of screen (size small) 2. Move the pointer over an entry in the taskbar or a quicklaunch icon.(System tray seems not to be affected except clock.) 3. Wait until the tooltip appears then move the pointer slowly towards the top of the screen. 4. As soon as the pointer leaves the task button the tooltip vanishes and if the pointer is only moved one more pixel it reappears and stays.
The tooltip is in a slightly different place when it re-appears and becomes stuck if that helps any. See screenshots: http://midgedog.orcon.net.nz/b1.png - Tooltip ok http://midgedog.orcon.net.nz/b2.png - Tooltip is slightly higher when it is stuck. ~Mike
Good day, I run KDE 3.0.5 on SuSE Linux Professional 8.1 and KDE 3.1.1 on SuSE Linux Professional 8.2 I can reproduce the kicker tooltip bug in both environments, but I can not reproduce the close button tooltip bug in either of the environments. In my setup of KDE 3.0.5 the tooltip for the clock often places itself on top of the log off button, thus blocking the ability to log off until the tooltip disappears by itself. In KDE 3.1.1 the tooltip always appears above the panel, and thus does not block anything in the panel. But it still ignores when the mouse leaves the panel and enters the tooltip's display area. In both cases I can reproduce the bug like this: The panel is at the bottom of the screen. The clock is rightmost in the panel and the log off applet to the left of the clock. - I hover the mouse in the clock until the tooltip appears. - I move the mouse straight down untill it hits the bottom of the panel/screen. - I move the mouse along the edge of the screen until it is just below the log off applet. - I move the mouse straight up, through the log off applet, and out of the panel. The tooltip stays on the screen, even though the mouse has left the panel, and even though I move the mouse into/over the tooltip. Best regards :o) Johnny :o)
*** Bug 58292 has been marked as a duplicate of this bug. ***
Is there any (usability) reason why tooltips could not be transparent and trans-clickable (allowing you to click on what ever was behind the tooltip, thru the tooltip)?
Usability wise tooltips should never get in touch with mouse pointers at all, ie. make them disappear or move away whenever they potentially obstruct a view near the mouse pointer.
I'm no longer able to reproduce the kicker tooltip bug with the current CVS HEAD of qt-copy and KDE. :-) Could it be that Lubos Lunak fixed it by removing the FocusIn hack for Qt 3.2? from cvs log of kdebase/kicker/core/container_panel.cpp: revision 1.79 date: 2003/05/21 14:50:33; author: lunakl; state: Exp; lines: +2 -0 Qt3.2 doesn't need the ugly faked FocusIn hack.
Neither can I, so I think this is fixed then..
It is not QT3.2 because i am running CVS with Qt: 3.1.1 and can't reproduce the bug either.
This seems a QT bug as opera has the same problem.
I fixed this in CVS HEAD some time ago. Since I haven't seen any problems as a result, I'll backport to 3.1 branch shortly.
I'm afraid I'm seeing this bug in KDE 3.2.0. If I move the mouse over the system tray icons, however quickly -- if I hit the edge of the screen, I end up with several tooltips (from each of the system tray icons that support tooltips), that will not disappear for a good 10 seconds. Sometimes I end up with 3-4 tooltips, and I cannot click on any icons they're obscuring, nor can I get rid of the tooltips until they dissapear on their own. KDE 3.2.0 QT 3.3.0 XFree86 4.3 - All compiled from sources (gcc 3.3.2, opt: -Os -march=athlon -mcpu=athlon -m3dnow -msse -mmmx -mfpmath=sse -fomit-frame-pointer -pipe) Not sure what other info I can provide... I can reproduce this exactly as the original submitter describes on 2002-06-15.
Same for me: I can reproduce this with 3.2.0
I can reproduce this quite often with 3.2.1 on a slow computer. Qt bug very likely, I'll have a look.
*** Bug 77397 has been marked as a duplicate of this bug. ***
On kde 3.2 (mandrake 10), the problem only seems to happen when the panel is placed on the upper edge of the screen (north).
Should be fixed for KDE3.2.2.
I concur, the bug appears to be fixed in KDE 3.2.2 (installed from Debian unstable).
I finally figured out why this was still happening at home, but not at work -- having the bottom panel set to "tiny" seems to trigger this bug very frequently, even with KDE 3.2.2. Any larger size seems to make it go away.