Bug 302364

Summary: If the mouse is in the wrong place it seizes focus of the Window Operation Menu
Product: [Plasma] Oxygen Reporter: Georgiy Treyvus <georgiytreyvus>
Component: styleAssignee: Hugo Pereira Da Costa <hugo.pereira.da.costa>
Status: RESOLVED FIXED    
Severity: normal CC: hugo.pereira.da.costa
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 4.9.1

Description Georgiy Treyvus 2012-06-22 18:40:27 UTC
I'm a heavy user of keyboard shortcuts. Like this bug is kind of hard to describe but I'll try my best.

Like say for example I wanted to toggle the maximization state of a window. I would go Alt-F3 and then x and all generally works. However say at the time I do this the pointer happens to be over where say the Move Window to Group section of the Window Operations Menu would appear then that thing is focused and the submenu appears. Now I can't press x to maximize. If I could press x then some other random unintended action would occur depending on what x was the accelerator key for. I am forced to use the arrow keys to navigate out of the submenu and over to the Maximize entry.

This does not happen in other desktops. If I were to do this say in GNOME and the mouse happened to hover over the wrong place nothing would happen until I either click the mouse or move it to wherever on the menu. Thus I can among other things toggle the maximization state of the window without worying where the mouse was before the Windows Operations Menu appeared. Thus Alt-Space then x is a trouble free keychain in any other desktop.

Now there are of course workarounds. I can go into System Settings and rig up keybindings to Minimize, Maximize, whatever. However that's a VERY cumbersome approach. This will cost several good keybindings. Furthermore these are hard to remember even if you rigged them yourself. Whereas otherwise I could have gone Alt-F3 and seen a menu full off underlined accelerator keys so I can quickly invoke what I remember or look up the next key in the chain for what I don't.

Anyway I hope I explained things properly. If you have any questions please ask and I will do my best to clarify. Also I've seen this issue on various versions of KDE, various Linux distributions, and PCBSD.

Reproducible: Always

Steps to Reproduce:
Look at details section.
Actual Results:  
Look at details section.

Expected Results:  
Look at details section.

Look at details section.
Comment 1 Thomas Lübking 2012-06-22 19:15:20 UTC
popups are not managed and grab the pointer, there's (nearly) nothing kwin could (but in this particular case) do.

it happens with the oxygen style only. try "kwin --replace --style <other_style>" to see.

@Hugo:
the OP concerns the fact that a showing up menu activates submenus immediately when they show up under the pointer, it's likely the animation code.

@Georgiy
You've a far better chance in getting bugs triaged and fixed if you at first stay with the point of your issue until being asked for more info or you actually run into a discussion, anticipatory argumentation is nothing but noise to the reader - this is not limited to KWin or KDE.
Comment 2 Hugo Pereira Da Costa 2012-06-23 09:08:00 UTC
Confirmed.
Definitely oxygen only, and definitely animations related.
Disabling Oxygen's animations fixes the issue.
Will investigate.
Comment 3 Hugo Pereira Da Costa 2012-07-09 14:45:06 UTC
Git commit b1170a116fb0eae03f95735efae0c4a69b42cfd4 by Hugo Pereira Da Costa.
Committed on 09/07/2012 at 16:37.
Pushed by hpereiradacosta into branch 'master'.

prevent calling mouseMoveEvent twice on menu enter.

M  +19   -4    kstyles/oxygen/animations/oxygenmenubardata.cpp
M  +24   -2    kstyles/oxygen/animations/oxygenmenubardata.h

http://commits.kde.org/kde-workspace/b1170a116fb0eae03f95735efae0c4a69b42cfd4
Comment 4 Hugo Pereira Da Costa 2012-07-09 14:46:03 UTC
Git commit 2509172ecf0157c8612a06c5c8fd777c2a2f280a by Hugo Pereira Da Costa.
Committed on 09/07/2012 at 16:37.
Pushed by hpereiradacosta into branch 'KDE/4.9'.

prevent calling mouseMoveEvent twice on menu enter.

M  +19   -4    kstyles/oxygen/animations/oxygenmenubardata.cpp
M  +24   -2    kstyles/oxygen/animations/oxygenmenubardata.h

http://commits.kde.org/kde-workspace/2509172ecf0157c8612a06c5c8fd777c2a2f280a
Comment 5 Hugo Pereira Da Costa 2012-07-09 14:47:18 UTC
Commit above fixes it in both master and KDE/4.9, so closing.
thanks for reporting the issue !

Hugo
Comment 6 Georgiy Treyvus 2012-08-25 17:03:31 UTC
Finally got to test KDE 4.9 via Chakra. Unfortunately this bug is still not fixed and persists in KDE 4.9. Please look into this again.
Comment 7 Georgiy Treyvus 2012-08-25 17:04:20 UTC
Finally got to test KDE 4.9 via Chakra. Unfortunately this bug is still not fixed and persists in KDE 4.9. Please look into this again.
Comment 8 Georgiy Treyvus 2012-08-25 17:05:15 UTC
Finally got to test KDE 4.9 via Chakra. Unfortunately this bug is still not fixed and persists in KDE 4.9. Please look into this again.
Comment 9 Georgiy Treyvus 2012-08-25 17:06:11 UTC
Somehow my above comment got put three times. Sorry for that. Bugzilla is wierd like that I guess.
Comment 10 Hugo Pereira Da Costa 2012-08-26 11:22:00 UTC
... damn you're right. Something must have gone wrong.
Will double check.
Comment 11 Hugo Pereira Da Costa 2012-08-29 11:45:57 UTC
Git commit 333f037f003b7deffa4412c44c5cfb822e78fe61 by Hugo Pereira Da Costa.
Committed on 29/08/2012 at 13:44.
Pushed by hpereiradacosta into branch 'KDE/4.9'.

Fix bug when resetting motions to -1 on enter event (stupid !)

M  +5    -1    kstyles/oxygen/animations/oxygenmenubardata.cpp

http://commits.kde.org/kde-workspace/333f037f003b7deffa4412c44c5cfb822e78fe61
Comment 12 Hugo Pereira Da Costa 2012-08-29 11:47:18 UTC
Git commit 56c5f43486d2c2fb4093b04862d2589f3743afae by Hugo Pereira Da Costa.
Committed on 29/08/2012 at 13:44.
Pushed by hpereiradacosta into branch 'master'.

Fix bug when resetting motions to -1 on enter event (stupid !)

M  +5    -1    kstyles/oxygen/animations/oxygenmenubardata.cpp

http://commits.kde.org/kde-workspace/56c5f43486d2c2fb4093b04862d2589f3743afae
Comment 13 Hugo Pereira Da Costa 2012-08-29 11:51:23 UTC
Stupid (very stupid) typo on my side, which would cause the bug to be fix only on *first* appearance of the menu. Hence the false-positive.
... now fixed for good. Re-closing