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 765181 - [Wayland] After renaming a file/folder, caret navigation and cursor is broken
[Wayland] After renaming a file/folder, caret navigation and cursor is broken
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.20.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks: WaylandRelated
 
 
Reported: 2016-04-17 16:01 UTC by Christian Stadelmann
Modified: 2016-05-13 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Stadelmann 2016-04-17 16:01:19 UTC
Steps to reproduce:
1. open nautilus
2. rename any file/folder, confirm (exit rename popover)
3. try to use caret navigation (use arrow keys, tab key, …)
4. rename another file/folder, watch out for the cursor

What happens:
3. doesn't work. No feedback.
4. no cursor available. Typing and mouse navigation in rename label still works

What should happen:
No changes to behavior before renaming files/folders, specifically:
3. caret navigation should work
4. cursor should be visible when renaming files/folders

Additional info:
gtk3-3.20.3-1.fc24.x86_64
glib2-2.48.0-1.fc24.x86_64
nautilus-3.20.0-1.fc24.x86_64
Comment 1 Christian Stadelmann 2016-04-17 16:02:39 UTC
As a note, after closing and re-opening nautilus (no matter whether the process ended or not), this issue is gone – until renaming another file/folder.
Comment 2 Carlos Soriano 2016-04-25 16:30:31 UTC
I tried this and it works here. I'm not sure I understand the bur report though.

So the problem is that the arrows navigation don't work after two renamings on different files? What is a cursor in this context?
Comment 3 Christian Stadelmann 2016-04-25 18:15:41 UTC
Ok, I think I missed to add some information:

This issue is only present on wayland backend, not on X11 backend.

To be more precise on "4." in #c0:
The mouse cursor "default" is still present. It still changes from "default" arrow to "text" and back. The vertical blinking line, also called cursor, is not visible any more when renaming a second file.

(cursor names from Gdk 3 documentation; using default Adwaita cursor theme)
Comment 4 Carlos Soriano 2016-04-26 08:19:16 UTC
Can you reproduce something similar in gtk3-demo?
Comment 5 Christian Stadelmann 2016-04-26 08:53:43 UTC
(In reply to Carlos Soriano from comment #4)
> Can you reproduce something similar in gtk3-demo?

I can not with "Delayed Search Entry" from gtk3-demo. I guess both are quite different though: "Delayed Search Entry" hides the GtkEntry, nautilus probably destroys it.

I haven't seen this issue in any other Gtk+ 3 application though, and I'm using quite many applications based on Gtk+ 3.x. I'd expect this to be an issue caused by Gtk+ code, but I cannot prove and don't know where to start debugging.
Comment 6 Christian Stadelmann 2016-04-26 18:17:49 UTC
I finally managed to reproduce this issue in gnome-builder:
1. open any project
2. open any file
3. rename any file in your opened project
4. put your mouse cursor into the editor

What happens:
The mouse cursor "default" is still present. It still changes from "default" arrow to "text" and back. The vertical blinking line, also called cursor, is not visible any more when editing the file.
When selecting a new file in left panel and pressing "F2", nothing happens.
Caret navigation in left panel is broken.

What should happen:
blinking text cursor should not hide.
Breaking focus for keyboard shortcuts and caret navigation should not happen.
Comment 7 Olivier Fourdan 2016-05-04 07:12:37 UTC
I wonder if it could be related to bug 762756

Which version of gtk+ are you running, do you have commit 14967d8 applied?
Comment 8 Christian Stadelmann 2016-05-04 09:29:28 UTC
> Which version of gtk+ are you running, do you have commit 14967d8 applied?

gtk3-3.20.3-1.fc24.x86_64(In reply to Olivier Fourdan from comment #7)

According to git [1], this is not yet applied to 3.20.3 and it is not patched in on Fedora either [2].

[1] https://git.gnome.org/browse/gtk+/log/?h=gtk-3-20
[2] https://pkgs.fedoraproject.org/cgit/rpms/gtk3.git/log/?h=f24
Comment 9 Christian Stadelmann 2016-05-04 09:31:49 UTC
Sorry, formatting broke. This is correct:

(In reply to Olivier Fourdan from comment #7):
> Which version of gtk+ are you running, do you have commit 14967d8 applied?

I'm running gtk3-3.20.3-1.fc24.x86_64

According to git [1], this is not yet applied to 3.20.3 and it is not patched in on Fedora either [2].

[1] https://git.gnome.org/browse/gtk+/log/?h=gtk-3-20
[2] https://pkgs.fedoraproject.org/cgit/rpms/gtk3.git/log/?h=f24
Comment 10 Olivier Fourdan 2016-05-04 11:22:53 UTC
I cannot reproduce neither comment 0 nor comment 6 here, so I am not sure...

Still, it reminds me of bug bug 762756 and bug 765477 (if the bug is the text cursor disappearing) so if you have the possibility to build a test package for gtk3 with the fix from commit 14967d8 cherry-picked, it would be useful.
Comment 11 Christian Stadelmann 2016-05-13 13:36:25 UTC
This issue is gone with an update to gnome 3.20.2 (Gtk+ 3.20.4). Thank you!