GNOME Bugzilla – Bug 642766
Rename Regression
Last modified: 2011-03-14 09:31:15 UTC
Steps to Reproduce: Select a file and choose "Rename" from the Edit menu. Actual Results: Using Nautilus (git version 2.91.9), the edit cursor is placed at the start of the file name. None of the file name's text is selected or highlighted. Expected Results: Using Nautilus (version 2.32.2.1), the file name is selected or highlighted. The selection does not include the file extension. For example, if the file name is "My Song.ogg" then the selected text is "My Song". The above regression applies to both the icon and compact views. As for the list view, sometimes choosing to rename a file results in the entire file name including extension being selected. At other times, rename does not work at all.
Created attachment 181475 [details] [review] patch the attached patch fixed the bug. the problem is that gtk_widget_grab_focus () indirectly calls eel_editable_label_state_changed (), which resets the selected region of the rename widged.
Review of attachment 181475 [details] [review]: Thanks, please push to master.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
I did a git update and pulled in the commit that is supposed to fix the bug. commit a8a5b8d8eae041e7ae10a553d0990fc7ee5dc3cd Author: Stefano Teso <steso@src.gnome.org> Date: Mon Feb 21 18:48:34 2011 +0100 icon-container: fix setting the selection when renaming Closes: bgo #642766 I am reopening this bug as the fix did not work here. The behaviour remains the same as described in the "Actual Results" in the bug description.
Mmm, odd, I just checked again, and I cannot reproduce the bug anymore on this machine. Did you try to do `make distclean` and rebuild everything again? Thanks.
Yes, I did a 'make distclean' then 'autogen.sh', 'make' and 'make install'. For the icon and compact views, the edit cursor is placed at the start of the file name. None of the name's text is selected or highlighted. Also, the below Gtk-CRITICAL is generated when rename fails for the list view. (nautilus:10466): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GtkEditable' (nautilus:10466): Gtk-CRITICAL **: gtk_editable_select_region: assertion `GTK_IS_EDITABLE (editable)' failed
I don't have much time, but I added few debug statements to the code. What I discovered was that eel_editable_label_select_region_index() is called twice when I select 'Rename'. Using the example where file name is "My Song.ogg", the first call to eel_editable_label_select_region_index() passes anchor_index = 0, end_index = 7. The second call passes anchor_index = 0, end_index = 0. The second call clears the selected text. Rename worked if I add the following near the top of the eel function. (i.e. "My Song" was highlighted.) if (anchor_index == end_index) return; Of course, the above is not a fix. The question is what is causing the second call? At that point, I ran out of time. I hope this information is helpful. Thanks.
Created attachment 181641 [details] [review] Workaround This is what I did for now to workaround the rename bug in the icon and compact views.
Dennis: I see, the "grab-focus" signal and the eel_editable_label_select_region () calls sometimes are not properly serialized. FWIW, I'd rather remove the 'eel_editable_label_select_region (label, 0, 0)' call from eel_editable_label_state_changed (). It is manually set by nautilus when editing starts, and manually reset when editing is finished. And nautilus-icon-container is the only user of EelEditableLabel anyway...
I borrowed a fix from GtkEntry for this; now it's fixed in master.
*** Bug 644622 has been marked as a duplicate of this bug. ***