Bug 180968 - Kickoff closes when moving mouse slowly away from K-Menu Icon
Summary: Kickoff closes when moving mouse slowly away from K-Menu Icon
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 183091 188563 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-16 14:26 UTC by Yves Glodt
Modified: 2009-05-09 02:03 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot showing other testcase (61.04 KB, image/png)
2009-01-26 22:46 UTC, Yves Glodt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yves Glodt 2009-01-16 14:26:52 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

To reproduce:

- Move cursor down to K-Menu
- Left-click it
- Move cursor slooowly upwards to reach kickoff
- See how kickoff closes while the cursor leaves the upper border of the K-menu icon
Comment 1 Aaron J. Seigo 2009-01-16 18:25:28 UTC
* no verson number provide

* i can't reproduce this
Comment 2 Yves Glodt 2009-01-16 21:21:58 UTC
Hi Aaron.

version is 4.1.96+svn907177-0r1 from the kde42.debian.net repo (work PC)

At home on Intrepid with the Kubuntu-provided 4.2rc1 packages I can neither reproduce it...

But I remember seeing it since some time on the debian box, at least since beta2.

I can provide more details on Monday
Comment 3 Yves Glodt 2009-01-17 13:09:47 UTC
Note that it seems the problem is just visible when a window is open behind kickoff. With all windows minimized the bug does not appear.

Here is a video demonstrating it:
http://www.mind.lu/~yg/bug180968/17012009.mp4
Comment 4 Yves Glodt 2009-01-17 13:11:29 UTC
It is independent of compositing, and I can reproduce it on two different installations (debian + kubuntu)
Comment 5 Yves Glodt 2009-01-26 22:46:48 UTC
Created attachment 30644 [details]
Screenshot showing other testcase

Hello,

I noticed another testcase of disappearing popups. The popup of the "Battery Monitor" plasmoid shows the same behaviour than kickoff.

It looks like the reason is, when you slowly move up the mouse, there is a small spot (1 line of pixel, marked  with red arrows in screenshot) between the panel and the popup, and when the mouse hovers this line, and another window is open behind the popup, then the popup vanishes. Note that it the bug does not happen when there is no window visible behind the popup.
Comment 6 Yves Glodt 2009-01-26 22:48:51 UTC
Note also that the calendar popup does not show the bug, most probably because there is no empty space between it and the panel (see previous screenshot), the calendar even covers the panel by a few pixels here.
Comment 7 Yves Glodt 2009-01-28 18:36:14 UTC
Does also happen with 4.2.0 here.
Comment 8 Yves Glodt 2009-01-28 23:42:32 UTC
Not sure it's "widget-kickoff" since it happens as well when moving the mouse away from battery applet.
Comment 9 Staffan Hamala 2009-03-12 11:29:42 UTC
I have this problem. Happens only if you use focus-follows-mouse (as I do).

Similar bug report:
https://bugs.kde.org/show_bug.cgi?id=183091
Comment 10 Martin Flöser 2009-03-31 21:25:07 UTC
*** Bug 188563 has been marked as a duplicate of this bug. ***
Comment 11 Reidaris 2009-03-31 23:21:46 UTC
Didn't see this bugreport, so i duplicated it (soz =S)

Anyway, when "focus-follows-mouse" is set (without autoraise or something, just the focus), it closes the popup-meny/window IF there is another application that coveres the area between the taskbar and the menu (the half centimeter of space between the button and the window that pops up).

To reproduce, follow #1 after maximising a application so it coveres the desktop.

Also, this isn't limited to kickoff, it happens with any "widget" on the bar that opens up a window (as example the device manager, battery monitor etc).

Gentoo (unstable), KDE4.2.1, amd64(no-multilib)
Comment 12 Reidaris 2009-04-22 18:57:27 UTC
Actually, didn't think of this before, but the easiest way of replicating is simply to open one of the the kickoff menu/devices/battery windows, and then hovering your mouse over another window on the screen. 
If focus-follows-mouse is set, this simply closes the menu, even without "auto-raise window" is set. Imo, default should be the menuwindow stays open until i decide to raise any other window i focus by clicking on it, since i don't have "auto-raise" set.
Comment 13 Anselmo L. S. Melo (anselmolsm) 2009-04-25 17:06:58 UTC
I can't reproduce this using trunk r958853 and I don't see that space between the panel and widget popups anymore.

Questions regarding focus-follow-mouse used to happen due that space. Hovering to another window isn't related with what was the initial bug reported - it's a matter of policy.
Comment 14 Aaron J. Seigo 2009-04-25 17:51:30 UTC
yes, the gap was fixed and, yes, focus follows will cause popup windows to go away like that. so .5 fixed and .5 wontfix :)
Comment 15 Staffan Hamala 2009-04-27 07:35:07 UTC
> yes, the gap was fixed and, yes, focus follows will cause popup windows to go
> away like that. so .5 fixed and .5 wontfix :)

That is wrong. Check, for example, KDE 3.5 - the menu does not go away if moving the mouse over other windows (not even if auto-raise is selected).

No window should ever go away or move to front or back just because "focus follows mouse" is used.
Comment 16 Aaron J. Seigo 2009-04-27 22:23:44 UTC
then use the "classic menu" in plasma. the regular popups hide when focus goes to another window.
Comment 17 Aaron J. Seigo 2009-05-09 02:03:43 UTC
*** Bug 183091 has been marked as a duplicate of this bug. ***