Comment 7 for bug 1741902

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.