Hi, 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. 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. But anyway, it shouldn't be possible to an application to lock-down a user session.
Created attachment 6664 Simple demo program (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...
(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.
(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.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/217. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev