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 164494 - Create folder text entry widget creates the folder when it loses focus
Create folder text entry widget creates the folder when it loses focus
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.4.x
Other All
: Normal normal
: Small fix
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 462814 479270 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-18 18:01 UTC by crouch
Modified: 2018-04-15 00:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6


Attachments
Python-GTK example of a case that is incorrect because of this fix (787 bytes, application/x-python)
2007-06-11 22:54 UTC, Tim Evans
  Details
CellRenderText: Improve focus out behavior (6.86 KB, patch)
2014-01-10 14:16 UTC, Phillip Wood
none Details | Review

Description crouch 2005-01-18 18:01:21 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:
Comment 1 Federico Mena Quintero 2005-01-18 21:47:17 UTC
This is a treeview bug.
Comment 2 Kristian Rietveld 2005-07-09 16:16:50 UTC
Editable cell renderers stop editing on focus changes. See bug 82405 and bug 87811.
Comment 3 crouch 2005-07-11 08:11:40 UTC
Your workaround is itself a bug. A directory should not be created just because
the widget looses focus. 
Comment 4 Kristian Rietveld 2006-12-10 20:53:45 UTC
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).
Comment 5 Kristian Rietveld 2007-01-03 19:35:26 UTC
Backmerged to gtk-2-10.
Comment 6 Tim Evans 2007-06-11 22:54:38 UTC
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?
Comment 7 Murray Cumming 2007-06-12 06:54:00 UTC
Reopening because it seems like this could cause data loss. And if so, that's a nasty thing to have backported to 2.10.
Comment 8 Kristian Rietveld 2007-08-02 19:29:48 UTC
*** Bug 462814 has been marked as a duplicate of this bug. ***
Comment 9 Kristian Rietveld 2007-09-24 18:31:35 UTC
*** Bug 479270 has been marked as a duplicate of this bug. ***
Comment 10 Paolo Borelli 2008-02-12 09:59:34 UTC
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... 
Comment 11 Murray Cumming 2011-06-23 22:00:35 UTC
Has
Comment 12 Murray Cumming 2011-06-23 22:01:17 UTC
Ignore that comment. I just wanted to add myself on CC.
Comment 13 Phillip Wood 2014-01-10 14:16:13 UTC
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
Comment 14 Phillip Wood 2014-04-29 13:11:50 UTC
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.
Comment 15 Matthias Clasen 2018-02-10 05:25:54 UTC
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.
Comment 16 Matthias Clasen 2018-04-15 00:35:50 UTC
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