Bug 362994 - middle click to close, in titlebar -passes click to whatever below
Summary: middle click to close, in titlebar -passes click to whatever below
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: core (other bugs)
Version First Reported In: 5.6.4
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-12 20:43 UTC by Allan
Modified: 2021-12-06 04:38 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan 2016-05-12 20:43:17 UTC
Assigning middle button to close in titlebar & frame - if mouse is moved just a tiny bit during the click, the click goes through after the window is closed - to underlying window or desktop.

Reproducible: Always

Steps to Reproduce:
1. Assign "Close" action to "Middle button" in "Titlebar & Frame"
2. Close a window with middle button in titlebar or frame -while "accidentally moving the mouse a pixel or more".
3. Be careful what you have in the clipboard buffer if the closed window was above a shell.. :p

Actual Results:  
Window is closed and usually clipboard is pasted somewhere or a stick-it note is opened on the desktop.

Expected Results:  
Just closing the window.
Comment 1 Martin Flöser 2016-05-13 05:46:20 UTC
That sounds like a bug in the applications. They react on a release although they never get a press event. The application should ignore that.

Do you see this with all applications or just e.g. all Qt applications?
Comment 2 Thomas Lübking 2016-05-13 06:54:27 UTC
Latter is easily tested: press in an xterm, move over to the problematic client and release the button there.
Is this with the breeze decoration, aurorae or both? (in doubt post output of "qdbus org.kde.KWin /KWin supportInformation")
Comment 3 Allan 2016-05-13 07:34:18 UTC
(In reply to Martin Gräßlin from comment #1)
> That sounds like a bug in the applications. They react on a release although
> they never get a press event. The application should ignore that.
> 
> Do you see this with all applications or just e.g. all Qt applications?

I see it in everything I've tested over so far, including: xterm, konsole plasma desktop.
Comment 4 Allan 2016-05-13 07:54:05 UTC
(In reply to Thomas Lübking from comment #2)
> Latter is easily tested: press in an xterm, move over to the problematic
> client and release the button there.
> Is this with the breeze decoration, aurorae or both? (in doubt post output
> of "qdbus org.kde.KWin /KWin supportInformation")

I only tested with Breeze.
Comment 5 Allan 2016-05-13 07:57:23 UTC
(In reply to Martin Gräßlin from comment #1)
> That sounds like a bug in the applications. They react on a release although
> they never get a press event. The application should ignore that.

I happens before release of the button.
I can reproduce it by clicking to close, then while still holding the button -move the mouse and the paste happen at the move action.
Comment 6 Martin Flöser 2016-05-13 08:08:38 UTC
at the move? That's something I would not have expected.
Comment 7 Allan 2016-05-13 09:05:28 UTC
(In reply to Martin Gräßlin from comment #6)
> at the move? That's something I would not have expected.

Affirmative, it only happens when mouse is moved during the press.
If the click is clean without any movement with the mouse, the click is not passed.
Comment 8 Thomas Lübking 2016-05-13 09:28:26 UTC
press, close move, paste? that's incredibly odd - the move would at least have to generate a release then...

running klipper process or plasmoid? still a problem when quitting those?
Comment 9 Allan 2016-05-13 13:58:57 UTC
(In reply to Thomas Lübking from comment #8)
> press, close move, paste? that's incredibly odd - the move would at least
> have to generate a release then...
> 
> running klipper process or plasmoid? still a problem when quitting those?

No klipper.

Also - this is the behaviour straight out of the box no addons or strange setups -you should be able to reproduce it easily just by following the steps to reproduce in the op. I certainly can on any computer with any mouse (with 2 buttons and a scroll wheel) and any recent kde5 I can remember (sorry I first got around to reporting the bugs now).
Comment 10 Allan 2016-05-13 17:29:03 UTC
Update, it does not seem to happen with Amarok, xev (darn..) and some GTK apps I just tried (browsers and gnome-terminal).

It so far happens all the time with:
Xterm
Konsole
Plasma desktop
Dolphin (starting a "draw a square", or closing a tab if above the tab.. eg. like a middle click)
System Settings (requires release of button aswell)
Libre-office math (requires release)
Comment 11 Thomas Lübking 2016-05-13 19:31:02 UTC
You cam make xev listen to other windows (just won't help in case this is related to some pointer grab):

   xev -event mouse -id <window id>
Comment 12 Allan 2016-05-13 19:47:07 UTC
(In reply to Thomas Lübking from comment #11)
> You cam make xev listen to other windows (just won't help in case this is
> related to some pointer grab):
> 
>    xev -event mouse -id <window id>

You're right - that gave nothing.
Comment 13 Allan 2016-05-18 19:14:41 UTC
Upgraded my KDE5 testing system to KDE 5.6.4 on Arch linux, changed the version and platform in this bug, because it is equally affected.

Suggestion for bug fix: make middle click to close behave like left click to close  on the close button.
- That means on release of the button + with cancel function by moving away from the button- or bar in this case.
Comment 14 Allan 2016-05-20 20:09:47 UTC
Just testing closing a window on middle click in Enlightenment WM above Konsole, as expected - nothing is passed down to Konsole.
Comment 15 kde.org 2021-11-06 17:31:51 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 16 Bug Janitor Service 2021-11-21 04:39:14 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 17 Bug Janitor Service 2021-12-06 04:38:35 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!