Mouse State locked to drag-drop state

Olivier Fourdan @olivier uploaded an attachment:

(In reply to LaMain from comment 0)

The Kmetronome app (most specificially a bug in it i think) put the mouse/keyboard focus in the drag-drop state, and can't return to normal. Which involve killing the session to get back stuff to normal.

Killing the application should suffice.

To reproduce the bug:

launch KMetronome

mouse-drag the tempo counter out of its window

KMetronome is a Qt app, and the 'tempo counter' inherits from QGraphicsView, which seems to be the root of the problem.

The window manager is not involved in the DnD mechanism, so I doubt the window manager is the problem here, have you tried with another window manager? (it's easy to replace the window manager at runtime without even restarting your session, e.g. "metacity --replace &" from a terminal within the running session)

But anyway, it shouldn't be possible to an application to lock-down a user session.

Unfortunately, nothing can be further from the truth in X11... That's why Wayland has no active grabs.

The way X works, any application can take an active grab on the keyboard and pointer and lock the session (that's how screen lock works actually!), the window manager cannot do anything about this.

So much that the X server itself used to have a mechanism (disabled by default for obvious reasons, as it would invalidate any screen lock, now removed entirely) to kill active grabs (that was option "AllowDeactivateGrabs" and "AllowClosedownGrabs", now removed)

Anyway, if you're not convinced, just save, build and run the attached source file (gtk+ 2.x) that will "lock" your session until you click the button...

Attachment 6664, "Simple demo program":
stuck.c

LaMain said:

(In reply to Olivier Fourdan from comment 1)

Thanks for your feedback.

(In reply to LaMain from comment 0)

The Kmetronome app (most specificially a bug in it i think) put the mouse/keyboard focus in the drag-drop state, and can't return to normal. Which involve killing the session to get back stuff to normal.

Killing the application should suffice.

Hey, that's the point, it did NOT suffice. Xfce is totally stuck even if the app is killed from non-X console.

To reproduce the bug:

launch KMetronome

mouse-drag the tempo counter out of its window

KMetronome is a Qt app, and the 'tempo counter' inherits from QGraphicsView, which seems to be the root of the problem.

The window manager is not involved in the DnD mechanism, so I doubt the window manager is the problem here, have you tried with another window manager? (it's easy to replace the window manager at runtime without even restarting your session, e.g. "metacity --replace &" from a terminal within the running session)

How could i use a terminal within a running session when keybords input are frozen ?

I can't affirm the windows manager is in cause, but the fact that focus is still stuck after the app is dead make me think so... I should add, that not all keyboard inputs are grabbed: can still use some Window-Manager shortcuts (like for killing foreground app, changing desktops ...)

But anyway, it shouldn't be possible to an application to lock-down a user session.

Unfortunately, nothing can be further from the truth in X11... That's why Wayland has no active grabs.

The way X works, any application can take an active grab on the keyboard and pointer and lock the session (that's how screen lock works actually!), the window manager cannot do anything about this.

So much that the X server itself used to have a mechanism (disabled by default for obvious reasons, as it would invalidate any screen lock, now removed entirely) to kill active grabs (that was option "AllowDeactivateGrabs" and "AllowClosedownGrabs", now removed)

Ok, thanks for the infos, and it seems ok that some app need that feature. But anyway, there's still a problem.

Anyway, if you're not convinced, just save, build and run the attached source file (gtk+ 2.x) that will "lock" your session until you click the button...

That's ok, you convince me.

Olivier Fourdan @olivier said:

(In reply to LaMain from comment 2)

Killing the application should suffice.

Hey, that's the point, it did NOT suffice. Xfce is totally stuck even if the app is killed from non-X console.

That's odd.

To reproduce the bug:

launch KMetronome

mouse-drag the tempo counter out of its window

KMetronome is a Qt app, and the 'tempo counter' inherits from QGraphicsView, which seems to be the root of the problem.

I tried to reproduce but on Fedora 24, KMetronome 1.0.0 with Qt 5.6.0, there is no way to drag and drop anything from the KMetronome window, so I have no way to reproduce.

How could i use a terminal within a running session when keybords input are frozen ?

connect remotely via ssh or switch to a console (if possible)

I can't affirm the windows manager is in cause, but the fact that focus is still stuck after the app is dead make me think so... I should add, that not all keyboard inputs are grabbed: can still use some Window-Manager shortcuts (like for killing foreground app, changing desktops ...)

On which window is the focus stuck once you killed the application?

You could try to restart xfwm4 (again, from ssh or a console) with "DISPLAY=:0.0 xfwm4 --replace" for example.

One interesting test would be to reproduce with a different window manager (like "metacity --replace"), that would help narrow the issue.

Closing as OP didn't reply to Olivier's last message.

closed

added 5. Drag-and-Drop 5. Mouse labels

Mouse State locked to drag-drop state

Submitted by LaMain

Description

Designs

Child items ...

Activity