GNOME Bugzilla – Bug 745859
Fails to show AskPassword dialog
Last modified: 2015-03-11 23:06:36 UTC
To reproduce: Enable gnome-user-share with a password. Click on "Browse Network" in Nautilus and then double-click on the share (e.g. "ross's public files on ..."). The Gnome shell does not show the password dialog like it is supposed to and the share is not mounted. The shell outputs: gnome-session[20151]: Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed The problem is that sometimes when you double click (especially if you release the mouse slowly), gtk may still be grabbing the pointer when the shell tries to run begin_modal, which fails causing the dialog not to be shown. I'm not sure what the best solution is here, but clearly the current behavior is not good :-(
Also see bug 737891 where this came up in a slightly different form.
A possibility would be to run the mount on double click release instead of double click press. Then the gtk grab would be already gone by the time the shell tries to obtain one.
It would be worth checking too what is creating the grab at this time. Surely GTK+ alone won't create an active grab on button press. If nautilus is creating it for selection/DnD purposes, it should be doing it at the right time (GTK+ grabs suffice for the former, and the active grab on the latter should only happen past the threshold)
Could it be the implicit X11 grab?
(In reply to Giovanni Campagna from comment #4) > Could it be the implicit X11 grab? No, don't think so... the implicit grab is "passive", X(I)AlreadyGrabbed should only be returned if the grab is actively grabbed elsewhere, this sounds like XIGrabDevice is called somewhere along the way. Although, trying nautilus on gdb, this seems to be true when clicking on blank areas (starting rubberbanding to be precise), but not when clicking on an item, unless you start dragging it, here's a backtrace of the former:
+ Trace 234823
(In reply to Carlos Garnacho from comment #5) > (In reply to Giovanni Campagna from comment #4) > > Could it be the implicit X11 grab? > > No, don't think so... the implicit grab is "passive", X(I)AlreadyGrabbed > should only be returned if the grab is actively grabbed elsewhere, this > sounds like XIGrabDevice is called somewhere along the way. Ok, ditch this. XIAlreadyGrabbed can be returned on the implicit grab if it is currently held by other client. /me gets more coffee
Created attachment 298906 [details] [review] Register double-click on button release Only perform the double-click action when the second click is released. This fixes a strange problem where double-clicking on a password-protected webdav share (as exported by gnome-user-share) fails to show the password dialog (which gnome-shell does) due to Nautilus holding a grab. By only taking action when the click is released, Nautilus is not holding a grab and the password dialog is shown. When it fails, the following is shown in the log: gnome-session[20151]: Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed
Well there's the approach mentioned in comment 2. Not sure if it is the right one but... To test it with a webdav share exported by gnome-user-share, you may need the patches from bug 629345.
(In reply to Ross Lagerwall from comment #8) > Not sure if it is the right one but... If it is, should we reassign to nautilus? I can't think off-hand of anything we could do on the shell side other than retrying once after a little timeout before giving up ...
Review of attachment 298906 [details] [review]: This approach looks fine to me, but I'm concerned that the details->double_clicked state is not cleared correctly on all the code paths. It should only ever be TRUE during the interval of time between the second button press being registered and the same button being released. Any other event should probably reset the state.
Created attachment 299072 [details] [review] Register double-click on button release Only perform the double-click action when the second click is released. This fixes a strange problem where double-clicking on a password-protected webdav share (as exported by gnome-user-share) fails to show the password dialog (which gnome-shell does) due to Nautilus holding a grab. By only taking action when the click is released, Nautilus is not holding a grab and the password dialog is shown. When it fails, the following is shown in the log: gnome-session[20151]: Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed
(In reply to Cosimo Cecchi from comment #10) > Review of attachment 298906 [details] [review] [review]: > > This approach looks fine to me, but I'm concerned that the > details->double_clicked state is not cleared correctly on all the code paths. > It should only ever be TRUE during the interval of time between the second > button press being registered and the same button being released. Any other > event should probably reset the state. OK, I've updated the patch but I'm not entirely sure of all the code paths etc.
Review of attachment 299072 [details] [review]: ::: libnautilus-private/nautilus-canvas-container.c @@ +5466,3 @@ + } + } + if (!button_event_modifies_selection (event_button)) { Either add a comment about falling through here, or return FALSE after this.
Created attachment 299120 [details] [review] Register double-click on button release Only perform the double-click action when the second click is released. This fixes a strange problem where double-clicking on a password-protected webdav share (as exported by gnome-user-share) fails to show the password dialog (which gnome-shell does) due to Nautilus holding a grab. By only taking action when the click is released, Nautilus is not holding a grab and the password dialog is shown. When it fails, the following is shown in the log: gnome-session[20151]: Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed
Review of attachment 299120 [details] [review]: Looks good to me.
Pushed to master as 3fe654aad79cdc549950018f2cff9bc87128ee83. Thanks for the reviews.