[General Responsiveness]: some clicks are eaten=not executed

[star-buck]

1. MENU-SWITCH: switch to alternative menu (kickoff to kicker or viceversa) first click on startbutton doesnt do anything (kubuntu-plasma5-201412051356-amd64.iso )
2. TASKS: right click on task-manager in panel area to bring up dialog, click on desktop to close it: next mouse click eaten, like clicking on menu button does nothing.
3. ICON in panel: right click on any icon in panel left-click somewhere on the desktop to close popup from right-click click on "Panel Edit" mode icon does nothing, only second click activates "edit mode"
4. WINDOW DRAG: click on top window bar to focus window: you can right-click on desktop click and hold to drag window to move around: you can not right-click on desktop after that (was possible under kde4.x)
5. KMIX (FIXED WITH NEW APPLET): left-click on kmix icon in systray while kmix dialog is open, try to grab and move a window from window titlebar

[mgraesslin]

1. MENU-SWITCH

I just tried that and can confirm.

[mgraesslin]

Any mouse event on the panel is lost when switching the menu. In fact any mouse event on the panel is eaten while the switch menu is open. This is different to other similar dialogs: systray and menu do not eat the event.

[mgraesslin]

5 KMIX is a bad example: it's using a QMenu and a QMenu grabs the mouse. If a widget grabs the mouse it's expected that no other elements can receive mouse events. That's the basic contract of a context menu and absolutely the expected behavior.

[star-buck]

well, in kde4.x you could have kmix open and still grab and move a window...just saying that this should be normal, expected behaviour.

[mgraesslin]

by that I'm not saying that I think it should work like that from a user perspective. But technically it has to work like that. It's opening a (context) menu and if that doesn't grab the mouse it becomes problematic.

The new Plasmoid is not showing that interaction as it's no longer a QMenu.

The same is the case for other similar menus. E.g. the old Klipper would have prevented mouse interaction, while the new doesn't.

[eikehein]

Just two notes:

a) The KMix popup is a QWidget, not a QMenu, and just from a casual glance I don't see it set a window type b) Clicking outside with the KMix popup open works fine here

[mgraesslin]

concerning a) not much difference. It's grabbing the mouse, I just verified by:

1. sleep 5 && xwininfo
2. open kmix
3. hover mouse over it
4. got: xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: error: Can't grab the mouse.

[eikehein]

There's not a single call to grabMouse() in the code tho and xwininfo works fine for me:

xwininfo: Please select the window about which you would like information by clicking the mouse in that window.

xwininfo: Window id: 0x380000f "kmix"

Absolute upper-left X: 1426 Absolute upper-left Y: 846 Relative upper-left X: 1426 Relative upper-left Y: 846 Width: 493 Height: 321 Depth: 32 Visual: 0xbe Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x380000e (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: yes Map State: IsViewable Override Redirect State: yes Corners: +1426+846 -1+846 -1-33 +1426-33 -geometry 493x321-1-33

--- snip ---

What's your kmix version? I have 4.6RC1 using KF5.5.

[mgraesslin]

Eike, might it be that you are running the Qt with the broken mouse grabbing?

[eikehein]

I'm on the 5.4 branch without the patch (unless it got in by now), sure.

[mgraesslin]

I'm on the 5.4 branch without the patch (unless it got in by now), sure.

so you are able to click outside and get xwininfo due to a Qt bug :-P

[mgraesslin]

can you test some more things: please try clicking on the task manager to close it. For me, the next event is not eaten in that case. If you can confirm that I have a theory to create a bug report against Qt.

[star-buck]

confirmed

[mgraesslin]

I am quite sure to have understood the root cause of the problem

1. MouseArea gets a mouse press event
2. The mouse press event triggers a context menu
3. The context menu performs grabKeyboard
4. The context menu is closed by clicking somewhere else, keyboard is released
5. The MouseArea didn't know anything about the keyboard grab and still thinks it is in pressed state
6. Next mouse press event on MouseArea is ignored as it's in wrong state

I'm sure to be able to construct a minimal example to illustrate the problem to Qt devs, but I'm not sure how and where this could be fixed.

[notmart]

Reported as upstream bug https://bugreports.qt.io/browse/QTBUG-43776

[notmart]

I'm not sure is 100% correct (and if will be accepted) but a tentative Qt patch is here: https://codereview.qt-project.org/#/c/104061/

[mgraesslin]

The package is libqt5gui5. Please note that the patch has regression potential.

[hsitter]

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-15-ci-fixes/+sourcepub/4691840/+listing-archive-extra

[star-buck]

still fails here even with updated packages from fixes ppa

[eikehein]

The good news is that it does work fine here (Qt 5.4 branch git which should have Marco's patch, Plasma git master which probably doesn't matter), so it has to be possible to get it working in principle ...

[notmart]

in the case of MENU-SWITCH seems to be reproducible locally too (oddly, some times, doesn't happen 100% of the times). I'll look into it, seems to be some other kind of issue comared to the original popup dismissing one actually, all the events seems to be blocked for the whole panel until a click happens.. i wonder if is related to deleting the item that accepted the right mouse button press (the old applet that gets replaced) @eikehein: so does it work for you after the switch?

[notmart]

doesn't seem directly related to the switching, even just opening the alternatives menu eats a click. if you unblock it before performing the switch, then you switch and the first click will be ok. so the problem is in the chain context menu->alternatives menu

[eikehein]

Here is my steps:

1. Right-click Kicker (or Kickoff)
2. Click Alternatives
3. Switch to the other menu
4. Click the menu icon

-> Menu opens.

[notmart]

interesting, wonder if is a different qt revision

[notmart]

this commit http://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=71b35c8b06220c1c31d29665c0559feb11055687 seem to fix the click issue with the alternatives dialog

[star-buck]

maybe it didnt got shipped, but here the annoying "alt-switch" issue can still be seen in action: https://www.youtube.com/watch?v=Dh7A7L-3KcQ#t=168

[notmart]

the commit is in master and 5.2, locally i still indeed see the problem happen sometimes

[star-buck]

so the bug is still not fixed, as it happens here all the time, not sometimes...

[star-buck]

lets check again on fridays kci and prepare to fix this once more.

[notmart]

So, the problem seems is related but not the same fixed by the Qt patch. I pushed in plasma-framework a patch to this problem in particular and is in this commit: http://commits.kde.org/plasma-framework/1794d3c43f9a1b60b1fd24946a865ba43352f50e

so it needs either an updated plasma-framework package or the above patch to be included.