After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 443785 - File operation dialogs should not be application-modal
File operation dialogs should not be application-modal
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.29.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 363614 390121 534959 540054 563884 581741 605471 613480 631636 633039 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-06-04 03:23 UTC by Andrew J. Montalenti
Modified: 2012-08-20 21:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
Add every window to its own window group (1.78 KB, patch)
2012-07-09 23:31 UTC, William Jon McCann
reviewed Details | Review
Add every window to its own window group (1.31 KB, patch)
2012-07-10 00:51 UTC, William Jon McCann
committed Details | Review

Description Andrew J. Montalenti 2007-06-04 03:23:20 UTC
Please describe the problem:
If Nautilus is doing a long-running operation in another workspace, when Nautilus encounters an error condition, the modal dialog will cause Nautilus to seem to "freeze" (that is, not respond to mouse clicks/keyboard presses) in the active workspace.

Steps to reproduce:
1. Run a long-running recursive delete on a folder that contains restrictive permissions in Workspace 2.
2. Switch to Workspace 1 and open a Nautilus folder.
3. When Nautilus encounters an error in Workspace 2, note how the windows of Nautilus don't respond in your active, Workspace 1. 


Actual results:
Nautilus "freezes".

Expected results:
Nautilus should be responsive.

Does this happen every time?
Yes.

Other information:
I don't think Nautilus should have modal dialogs altogether.  What's the point, really?
Comment 1 Caleb Eggensperger 2009-06-25 06:18:53 UTC
I can confirm this bug -- dialogs seem to be application-modal instead of window-modal. An easier way to demonstrate it:

1. Open two nautilus windows (or use desktop and one window)
2. Double click on an executable text file in one of them, yielding the "Do you want to run this or display its contents" dialog box.
3. Switch to the other window (without responding to the dialog box). The window is "stuck" -- closing it doesn't work, clicking on things doesn't work (tooltips strangely do still work)

This is really frustrating.
Comment 2 Sense Hofstede 2009-12-22 12:55:48 UTC
I can confirm that in 2.28 as well any modal dialogue from Nautilus will block all Nautilus instances, which means that until you've answered the question you can't use any desktop, workspace and Nautilus window.

In my eyes the best solution would be to remove all modal dialogues since it has been argued many times that modal dialogues are Bad Things.
If that's not what the developers want I would suggest to at least make the dialogue just block the affected Nautilus window and not half your computer.
Comment 3 Benedict Stein 2010-02-17 17:16:31 UTC
Confirming this too - e.g. using the blank DVD tool.

Did you ever wait 15 mins until your file browser is back ? - needs to be solved!
Comment 4 Cosimo Cecchi 2010-02-22 00:36:53 UTC
*** Bug 581741 has been marked as a duplicate of this bug. ***
Comment 5 Cosimo Cecchi 2010-02-22 00:37:26 UTC
*** Bug 605471 has been marked as a duplicate of this bug. ***
Comment 6 Marcus Carlson 2010-07-21 20:50:12 UTC
*** Bug 390121 has been marked as a duplicate of this bug. ***
Comment 7 Marcus Carlson 2010-07-21 20:50:32 UTC
*** Bug 613480 has been marked as a duplicate of this bug. ***
Comment 8 Marcus Carlson 2010-07-21 21:07:36 UTC
*** Bug 363614 has been marked as a duplicate of this bug. ***
Comment 9 Cosimo Cecchi 2010-10-08 13:01:40 UTC
*** Bug 631636 has been marked as a duplicate of this bug. ***
Comment 10 Cosimo Cecchi 2010-10-24 17:29:34 UTC
*** Bug 633039 has been marked as a duplicate of this bug. ***
Comment 11 Cosimo Cecchi 2011-01-17 15:06:17 UTC
*** Bug 563884 has been marked as a duplicate of this bug. ***
Comment 12 Cosimo Cecchi 2011-01-17 15:18:34 UTC
*** Bug 534959 has been marked as a duplicate of this bug. ***
Comment 13 William Jon McCann 2012-07-09 23:31:58 UTC
Created attachment 218369 [details] [review]
Add every window to its own window group

This prevents window modal dialogs from blocking the entire app.
Comment 14 Cosimo Cecchi 2012-07-09 23:57:41 UTC
Review of attachment 218369 [details] [review]:

::: src/nautilus-window.c
@@ +2273,3 @@
 
+	window->details->window_group = gtk_window_group_new ();
+	gtk_window_group_add_window (window->details->window_group, GTK_WINDOW (window));

Looks good, thanks!

I think you can avoid storing the window group as a private member of the window object, since the docs say

"GtkWindowGroup objects are referenced by each window in the group, so once you have added all windows to a GtkWindowGroup, you can drop the initial reference to the window group with g_object_unref()."

and we only ever add one window to each group.
Comment 15 William Jon McCann 2012-07-10 00:51:55 UTC
Created attachment 218371 [details] [review]
Add every window to its own window group

This prevents window modal dialogs from blocking the entire app.
Comment 16 Cosimo Cecchi 2012-07-10 13:03:54 UTC
Review of attachment 218371 [details] [review]:

Looks great, thanks!
Comment 17 William Jon McCann 2012-08-20 21:19:56 UTC
*** Bug 540054 has been marked as a duplicate of this bug. ***