GNOME Bugzilla – Bug 443785
File operation dialogs should not be application-modal
Last modified: 2012-08-20 21:19:56 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?
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.
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.
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!
*** Bug 581741 has been marked as a duplicate of this bug. ***
*** Bug 605471 has been marked as a duplicate of this bug. ***
*** Bug 390121 has been marked as a duplicate of this bug. ***
*** Bug 613480 has been marked as a duplicate of this bug. ***
*** Bug 363614 has been marked as a duplicate of this bug. ***
*** Bug 631636 has been marked as a duplicate of this bug. ***
*** Bug 633039 has been marked as a duplicate of this bug. ***
*** Bug 563884 has been marked as a duplicate of this bug. ***
*** Bug 534959 has been marked as a duplicate of this bug. ***
Created attachment 218369 [details] [review] Add every window to its own window group This prevents window modal dialogs from blocking the entire app.
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.
Created attachment 218371 [details] [review] Add every window to its own window group This prevents window modal dialogs from blocking the entire app.
Review of attachment 218371 [details] [review]: Looks great, thanks!
*** Bug 540054 has been marked as a duplicate of this bug. ***