Bug 371229 - Drag starts on window below if window dragged on closes while dragging
Summary: Drag starts on window below if window dragged on closes while dragging
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 5.8.2
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-19 16:36 UTC by Matthias Fauconneau
Modified: 2016-10-28 11:18 UTC (History)
0 users

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


Attachments
attachment-25958-0.html (1.60 KB, text/html)
2016-10-28 10:55 UTC, Matthias Fauconneau
Details
attachment-27035-0.html (2.39 KB, text/html)
2016-10-28 11:10 UTC, Matthias Fauconneau
Details

Note You need to log in before you can comment on or make changes to this bug.
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.