GNOME Bugzilla – Bug 164494
Create folder text entry widget creates the folder when it loses focus
Last modified: 2018-04-15 00:35:50 UTC
Please describe the problem: In firefox (but also other gtk2.4 apps), If I press "Create Folder" I get a text entry widget containing "Type name of new folder". If I change focus to the browser window a folder called "Type name of new folder" is created immediately. This should not happen until I hit <enter> Steps to reproduce: 1. run firefox 2. file -> save page as 3. Create Folder 4. Move focus to browser window Actual results: A folder is created immediately Expected results: The entry widget should wait for more input until <enter> is pressed Does this happen every time? yes Other information:
This is a treeview bug.
Editable cell renderers stop editing on focus changes. See bug 82405 and bug 87811.
Your workaround is itself a bug. A directory should not be created just because the widget looses focus.
Changed the text renderer on HEAD to cancel editing when the tree view loses focus. 2006-12-10 Kristian Rietveld <kris@gtk.org> * gtk/gtkcellrenderertext.c (gtk_cell_renderer_text_focus_out_event): cancel editing (ie. don't accept changes) when the entry loses focus. (Fixes #164494, reported by Chris Rouch).
Backmerged to gtk-2-10.
Created attachment 89779 [details] Python-GTK example of a case that is incorrect because of this fix The attached script demonstrates a case where this fix goes against user expectations. This is based on a real case we ran into with our application. When you run the script a dialog appears that lets the user edit a list of strings. Having changed one of the strings, the user clicks the "OK" button. The problem is that, to the user, there is no indication that they need to press enter to commit the change to the list before they click OK. They see the list item having the correct value, but when they click OK to confirm it focus is given to the OK button, cancelling the edit. If they press enter, tab, even up or down arrow then the edit is confirmed, but if they click the button or press the Alt+O mnemonic the edit is cancelled. Is there any chance this bug could be reopened and the change reverted until a more complete solution is found?
Reopening because it seems like this could cause data loss. And if so, that's a nasty thing to have backported to 2.10.
*** Bug 462814 has been marked as a duplicate of this bug. ***
*** Bug 479270 has been marked as a duplicate of this bug. ***
This problem has also come up multiple times in gedit: for instance people rename an "External Tool" script and then click on another field of the dialog and the rename is lost leaving the user puzzled... what about having two different signals, e.g. "edited" and "edit-confirmed" where the first is emitted also on focus out while the other only when enter is pressed...
Has
Ignore that comment. I just wanted to add myself on CC.
Created attachment 265923 [details] [review] CellRenderText: Improve focus out behavior Canceling editing on focus out causes problems when editing tracks in sound-juicer as it very easy to lose your changes especially when copying and pasting the track names from another application. This patch changes the behavior of the file chooser slightly - when the user presses the up or down arrow or clicks in the treeview while editing a new directory name the editing is canceled rather than creating the new directory. This seems to make sense if the aim is to require explicit confirmation of the creation of new directories and avoids accidentally creating a new directory when the user clicks on an existing one. Restoring the behavior of the arrow keys would be trivial, clicking on the treeview less so. The changes to gtk_tree_view_stop_editing ensure that either "editing-canceled" or "edited" is always emitted, without them if gtk_cell_area_stop_editing is called with canceled == FALSE "editing-canceled" is not emitted but if the "editing-canceled" property of the editable is TRUE then GtkCellRendererText doesn't emit "edited" either. It might be better to put this logic in gtk_cell_area_stop_editing instead. A cell editable only needs to end editing when the focus passes to another widget in the same window. If the focus passes to another window then the user should be able to resume editing when they return to the original window. Use gtk_widget_is_focus rather than gtk_widget_has_focus to avoid unnecessarily ending editing. The current behavior of canceling the changes whenever the cell renderer looses the input focus is confusing and causes users to lose changes [1,2]. It was introduced to ensure the user confirms the creation of a new directory in the file chooser. Fix the file chooser by only setting "editing-canceled" to FALSE if the user presses Enter and restore better behavior to the CellRendererText. Applications that require the user to explicitly confirm changes can use the "editing-canceled" property of the cell editable to reject the changes unless they press enter as the file chooser does. [1] https://bugzilla.gnome.org/show_bug.cgi?id=479270 [2] https://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00082.html
Any chance of some feedback on this? Another approach that doesn't change the current behaviour would be to add a property to select if changes need to be confirmed or not.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new