Drag and drop state may be freezed by rogue application

[dronus]

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)

[dronus (paul-geisler)]

Please add critical as bug results in system state forcing users to hard reboot with potential data loss.

[Alberts Muktupāvels (muktupavels)]

Why do you think that Metacity is the one who freezes? Have you tried other window managers and/or sessions and this happens only with Metacity?

The thing is that Metacity does not do anything with drag and drop so that might be bug in nautilus and/or xserver.

Can you provide steps that I can use to reproduce problem?

[dronus (paul-geisler)]

I thought Metacity is the component that has to deal with inter-application interaction. Seems I am wrong?

I already know that a bug in nautlius is the trigger of the problem, however no application should be able to lock drag and drop state on its own without any way to exit it.

So the only target left to file this bug is the X server?

[Alberts Muktupāvels (muktupavels)]

Well, I don't know how drag & drop works so I can not say that it is bug in X server. I would start by reporting / re-assigning this bug to nautilus especially if it is only app that causes this problem.

[dronus (paul-geisler)]

As I already mentioned, I am aware that nautilus is triggering the problem. However, no program should be able to bring down the desktop by doing bad UI operations. Period.

So wether metacity or Xorg or anything I never even heard of is the right space to solve this issue is out of my reach, because I don't know their parts in handling drag and drop operations. The developers would know.

If you tell me "metacity has no part in drag and drop at all", I guess Xorg is to blame, so you maybe move the bug there?

[Alberts Muktupāvels (muktupavels)]

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.