Bug 371229

Summary:	Drag starts on window below if window dragged on closes while dragging
Product:	[Plasma] kwin	Reporter:	Matthias Fauconneau <matthias.fauconneau>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal
Priority:	NOR
Version First Reported In:	5.8.2
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	attachment-25958-0.html attachment-27035-0.html

Description Matthias Fauconneau 2016-10-19 16:36:08 UTC

I have a program where I drag (move the mouse while a button is pressed) to change the view.
If the program closes during the drag (crashes) and I keep dragging (without releasing and pressing the mouse button again), a new drag selection starts on the window below (e.g QtCreator or KWrite).

This new drag is not wanted, I would expect a drag on the next window to only occur once I release and press the button again.
When dragging over the bounds of a window, the windows below correctly ignore the mouse motion, the same should happen when the window closes so long the mouse button is not released and pressed again.

Reproducible: Always

Comment 1 Martin Flöser 2016-10-20 05:40:46 UTC

That's on X11 or Wayland?

Comment 2 Martin Flöser 2016-10-28 10:46:04 UTC

We need to know which windowing system is used for further investigation. In general: on X11 kwin cannot do anything about that. On Wayland that should not happen as KWin doesn't update pointer focus while a pointer button is down.

Comment 3 Matthias Fauconneau 2016-10-28 10:55:17 UTC

Created attachment 101848 [details]
attachment-25958-0.html

This is on X11.
I guess that's a reason to use Wayland then...
No workarounds are possible on X11 ?


On Fri, Oct 28, 2016 at 12:46 PM, Martin Gräßlin <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=371229
>
> Martin Gräßlin <mgraesslin@kde.org> changed:
>
>            What    |Removed                     |Added
> ------------------------------------------------------------
> ----------------
>              Status|UNCONFIRMED                 |NEEDSINFO
>          Resolution|---                         |WAITINGFORINFO
>
> --- Comment #2 from Martin Gräßlin <mgraesslin@kde.org> ---
> We need to know which windowing system is used for further investigation.
> In
> general: on X11 kwin cannot do anything about that. On Wayland that should
> not
> happen as KWin doesn't update pointer focus while a pointer button is down.
>
> --
> You are receiving this mail because:
> You reported the bug.

Comment 4 Martin Flöser 2016-10-28 11:04:37 UTC

Well on X11 the window manager is not involved in that. The first drag is handled inside the application - the second drag as well. For the second application there is no chance to know what was going on.

In fact as far as I understand the problem from an X11 protocol point of view everything seems fine. A pointer enter is supposed to be sent to the window below the cursor as soon as the other window crashes. And the window then reacts.

On Wayland the compositor has a little bit more choice, luckily:

case QEvent::MouseMove: {
            if (event->buttons() == Qt::NoButton) {
                // update pointer window only if no button is pressed
                input()->pointer()->update();
            }

Comment 5 Matthias Fauconneau 2016-10-28 11:10:13 UTC

Created attachment 101849 [details]
attachment-27035-0.html

Thank you for the information.
So I guess it would need either an X server hack, or the application
(toolkit) should only start drags when the mouse move is after a mouse
press on its window. Actually that's what I do in my app, I wonder why is
it not the normal way applications (toolkits) handle drag starts ? maybe
some interaction with inter application drags ?

On Fri, Oct 28, 2016 at 1:04 PM, Martin Gräßlin <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=371229
>
> Martin Gräßlin <mgraesslin@kde.org> changed:
>
>            What    |Removed                     |Added
> ------------------------------------------------------------
> ----------------
>          Resolution|WAITINGFORINFO              |INVALID
>              Status|NEEDSINFO                   |RESOLVED
>
> --- Comment #4 from Martin Gräßlin <mgraesslin@kde.org> ---
> Well on X11 the window manager is not involved in that. The first drag is
> handled inside the application - the second drag as well. For the second
> application there is no chance to know what was going on.
>
> In fact as far as I understand the problem from an X11 protocol point of
> view
> everything seems fine. A pointer enter is supposed to be sent to the window
> below the cursor as soon as the other window crashes. And the window then
> reacts.
>
> On Wayland the compositor has a little bit more choice, luckily:
>
> case QEvent::MouseMove: {
>             if (event->buttons() == Qt::NoButton) {
>                 // update pointer window only if no button is pressed
>                 input()->pointer()->update();
>             }
>
> --
> You are receiving this mail because:
> You reported the bug.
>

Comment 6 Martin Flöser 2016-10-28 11:18:14 UTC

yeah I would assume that an application only starts the drag on a button press and not on pointer enter.