GNOME Bugzilla – Bug 748501
Double click on folders does not work
Last modified: 2017-08-28 12:57:18 UTC
Sometimes, double clicking on a item in nautilus icon view does not work - it does not open the file/folder, and I see no visible effect. In those cases, trying again a couple times might succeed, but it's quite annoying because it's completely unpredictable. In all cases, pressing enter has the desired effect. This is nautilus-3.16.1-1.fc22.x86_64 under X11, configured with double click to open items. If it matters, I'm using the libinput driver, and the click is happening on a clickpad touchpad - but clicks are reported correctly in all other apps.
I can't reproduce, but some colleague reproduced it in x11 and wayland. Marking as blocker for 3.16.x
I wouldn't be surprised if this bug is related to the recently fixed bug 748265 , so it would be interesting to know if someone could still reproduce the issue with current nautilus git master.
(In reply to Nelson Benitez from comment #2) > I wouldn't be surprised if this bug is related to the recently fixed bug > 748265 , so it would be interesting to know if someone could still reproduce > the issue with current nautilus git master. It doesn't have anything to do with that...
*** Bug 746849 has been marked as a duplicate of this bug. ***
I am running OpenSuse Tumbleweed with GNOME version 3.16.1 and I am having the same issue with double click. I can't reproduce the issue with X11, but it does happen with Wayland. Switching to single click and List mode for viewing does not have this issue
A similar issue with Gnome-3.16 under Gentoo. It's present on my desktop (with wacom graphics tablet?) but not on my laptop with trackpad. Changing to single click works perfectly, changing back no luck. Double click speed is fine, and double clicks are registered by the mouse "test my settings" option fine. If I can provide any additional information, please let me know...
*** Bug 749448 has been marked as a duplicate of this bug. ***
*** Bug 749619 has been marked as a duplicate of this bug. ***
I've also been running into this issue. Often, when double-clicking on a folder **does** result in the cursor spinning, it will just continue to spin indefinitely until I move the mouse outside of the window. I wasn't sure if these were two symptoms of the same problem or not.
> Often, when double-clicking on a folder **does** result in the cursor spinning, it will just continue to spin indefinitely until I move the mouse outside of the window. I wasn't sure if these were two symptoms of the same problem or not. This seems to have been fixed at some point, so no bueno. Couple notes: 1) I **have** occasionally been able to reproduce this in List View, but it seems much less common. 2) If you keep clicking, it will work eventually.
I can reproduce in Wayland, so it's a serious blocker for some distros that wants to switch to Wayland like Fedora. I will take a look soon.
Fixed in 3.17.90.
(In reply to Juraj Fiala from comment #12) > Fixed in 3.17.90. In wayland as well? Code wasnt changed in nautilus.
Yes, I'm pretty positive it works. Both under X and Wayland. > Code wasnt changed in nautilus. Didn't nautilus get like the most changes in 3.17?
(In reply to Juraj Fiala from comment #14) > Yes, I'm pretty positive it works. Both under X and Wayland. > > > Code wasnt changed in nautilus. > > Didn't nautilus get like the most changes in 3.17? Depending on what changes you mean. In this case, no, any change was done on this front.
nautilus 1:3.18.2-1ubuntu2 running on Ubuntu 16.04 testing. Yesterday's update gave a menu with no method of deleting, rather than moving files/directories to the recycle bin. This is an upstream bug.
Bugzilla didn't offer me a bug anything like this. Sorry. If I need to report it again please let me know.
Running 3.18.5 on Arch, and sometimes double clicks are not recognized/processed. Not sure if it's the mouse or Nautilus. Is there a way to debug that?
I have the same problem. It is usually OK, but slow to work on a top level directory. With seven or eight levels of subdirectories fails miserably. It's been like that since the very early day of pre-alpha in Ubuntu 16.04. AQnd I can assure you, there is no workaround. The problem is far less evident at the beginning of a work session. After a couple of hours or so, it becomes almost unusable by double clicking. Should I be advising Canonical to move to a different browser for Xenial release? Regards, Barry.
I have the same problem with Nautilus on arch but only on desktop not on my laptop (both running almost identical installs). After a bit of testing I think I've found the issue. If pressing double click causes any vibration in the mouse and causes the cursor to move even slightly while on an icon double click does not register. If you hold the mouse perfectly still and double click it works every time· So my findings are that any movement of the mouse cursor while double clicking an icon in icon view interrupts the click event being registered. This also explains why it is intermittent for some people or non existent for others as it will be dependent on the mouse sensitivity and whether your mouse is on a stable mouse mat / platform etc. List view still works fine, so I'm wondering whether icon view registers the are of the icon the click is registered and whether any movement of cursor on click resets that listener???? Hope this helps.
(In reply to james from comment #20) > I have the same problem with Nautilus on arch but only on desktop not on my > laptop (both running almost identical installs). After a bit of testing I > think I've found the issue. > > If pressing double click causes any vibration in the mouse and causes the > cursor to move even slightly while on an icon double click does not register. > > If you hold the mouse perfectly still and double click it works every time· > > So my findings are that any movement of the mouse cursor while double > clicking an icon in icon view interrupts the click event being registered. > > This also explains why it is intermittent for some people or non existent > for others as it will be dependent on the mouse sensitivity and whether your > mouse is on a stable mouse mat / platform etc. > > List view still works fine, so I'm wondering whether icon view registers the > are of the icon the click is registered and whether any movement of cursor > on click resets that listener???? > > Hope this helps. I should add I am on Nautilus 3.18.5-1 but I assume the same issue
Nice one! I can confirm this. Slight movement during double clicking has indeed no effect in list but in icon view. So depending on the sensitivity of the mouse, this may or may not happen.
Created attachment 327539 [details] [review] Do not reset double click status on pointer movement
This seems to have been introduced in the fix for bug 745859. The problem is that container->details->double_clicked is set to false on any event, also pointer movements. I'm not sure if the problem in bug 745859 is reintroduced by the patch as I could not get gnome-user-share to work without NetworkManager.
Cosimo, this makes sense to me, but I would like your review based on the bugs linked on comment 24.
Review of attachment 327539 [details] [review]: If I correctly follow the code, the problem would only happen if the pointer is moved between the second button press and the second button release: the button press handler will set double_clicked = TRUE, which is then consumed by the button release handler. Either way, this looks good to me, feel free to push!
Is there anything left for me to do that is blocking this from getting pushed? Also, just out of curiosity, will this be backported to 3.20 so that we can enjoy double clicks there again? ;)
Hey Johannes, No, nothing left, thanks for the heads up. Also seems git bz failed, here is the pushed commit. https://git.gnome.org/browse/nautilus/commit/?id=e96f73cf1589c023ade74e4aeb16a0c422790161
and to 3.20: https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-20&id=5689f36e82728447a78beaca67576bbd633666bf
Great, thank you, Carlos!
*** Bug 762527 has been marked as a duplicate of this bug. ***