>From your bug: "Windows can still be bought to front by clicking them, but never gain focus and no application (besides nautlilus I guess, which is stalled) receives clicks or keystrokes."
This sounds like nautilus has grabbed mouse & keyboard when it started drag & drop operation. From what I know it is perfectly valid action on X. Any app can grab keyboard and/or mouse... https://freedesktop.org/wiki/Specifications/XDND/ Read "Protecting against malfunctioning programs" section. It seems that it is application responsibility to make sure it does not crash and/or lock (doesn't wait forever). Reading your bug seems that nautilus just enters in "waiting forever" state when sftp connection drops. It just waits for something that will never happen and also does not ungrab keyboard and/or mouse. Yes, that is bad, very bad situation... But I don't see how this could be fixed somewhere else. Metacity (window manager) is not involved here, also I think there is nothing to fix in X. How can X know that application has entered some bad state? Nautilus most likely can detect that connection drops and in such case it must make sure that any started drag & drop operation is cancelled. If that happens with other apps, then it might be bug at toolkit level - gtk+. Can you provide steps how to reproduce this bug? Might be good idea to forward bug to upstream project: https://gitlab.gnome.org/GNOME/nautilus Maybe nautilus developers has already fixed this in newer versions. My 16.04 installations shows 1:3.18.4.is.3.14.3-0ubuntu6 as nautilus version which is very old version. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1741902 Title: Drag and drop state may be freezed by rogue application Status in metacity package in Ubuntu: New Status in nautilus package in Ubuntu: New Bug description: I had some issues with nautlilus in the past time, that of cause need to be resolved by the nautlilus devs, but it turns out that IO freezes (eg. dropped sftp connections) may freeze nautlilus while drag and drop operations, and hence freeze metacity in some kind, as d&d seems to lock some control to the participating applications. What I do: Drag a file from nautilus. What happens: Nautilus blocks for some reason, eg. dropped sftp connection. The mouse pointer stays in dragging state after releasing the mouse button. No drop action is executed. Windows can still be bought to front by clicking them, but never gain focus and no application (besides nautlilus I guess, which is stalled) receives clicks or keystrokes. If at some point nautilus crashes in turn, the system usability is fully restored. If not, a restart by hard shutdown is needed to regain control. What should happen: If an application fails to commence it's drag and drop interaction, the action should be canceled on metacity's behalf. Otherwise any rogue application can stop user interaction down to moving the pointer around, requiring hard reboot. Security considerations: Low. The freezed state seems to block screen locking, and may reveal an unprotected desktop if the rogue application releases control at some point, eg. by crashing. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: metacity 1:3.18.7-0ubuntu0.3 ProcVersionSignature: Ubuntu 4.4.0-105.128-generic 4.4.98 Uname: Linux 4.4.0-105-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: GNOME-Flashback:Unity Date: Mon Jan 8 14:52:41 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2016-08-23 (503 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: metacity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/1741902/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
