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 419737 - File save dialog deletes/empties filename when changing directory
File save dialog deletes/empties filename when changing directory
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
Other All
: Normal major
: ---
Assigned To: Federico Mena Quintero
Federico Mena Quintero
: 355756 429706 434293 450852 453383 461035 483277 494037 495352 497074 510517 (view as bug list)
Depends on:
Reported: 2007-03-18 14:50 UTC by Thilo Six
Modified: 2008-06-19 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22

Code to test GtkFileChooserDialog in a few ways (2.22 KB, text/plain)
2008-01-04 12:44 UTC, Olle Bergkvist
Patch (diff -ru) to fix Bug 419737 on GTK+ 2.10.14 (1.36 KB, patch)
2008-01-10 17:07 UTC, Olle Bergkvist
none Details | Review
Patch (svn diff) to fix Bug 419737 on current GTK+ trunk (994 bytes, patch)
2008-01-10 17:14 UTC, Olle Bergkvist
none Details | Review
updated patch for 2.10.14 (1.90 KB, patch)
2008-01-10 21:13 UTC, Olle Bergkvist
none Details | Review
updated patch for updated SVN trunk (1.57 KB, patch)
2008-01-10 21:18 UTC, Olle Bergkvist
none Details | Review
updated cleaner patch for SVN trunk (2.66 KB, patch)
2008-01-28 22:39 UTC, Olle Bergkvist
none Details | Review
gtk-filechooser-dont-focus-file-list.diff (1.56 KB, patch)
2008-02-05 23:22 UTC, Federico Mena Quintero
committed Details | Review
gtk-filechooser-dont-focus-file-list-shortcut.diff (1.87 KB, patch)
2008-02-12 19:34 UTC, Federico Mena Quintero
committed Details | Review
New Test Case (3.27 KB, text/plain)
2008-06-17 14:24 UTC, Olle Bergkvist
Fixes the main problem, file name check, SAVE mode (508 bytes, patch)
2008-06-17 14:32 UTC, Olle Bergkvist
none Details | Review
Fixes an additional entry erasing problem in CREATE_FOLDER (743 bytes, patch)
2008-06-17 14:34 UTC, Olle Bergkvist
none Details | Review

Description Thilo Six 2007-03-18 14:50:39 UTC
Please describe the problem:
When i open the file save dialog and change the directory, the file name get emptied and must be typed by hand.

This happens in gedit (save as) and gnome-btdownload when changing the destiny directory

Steps to reproduce:
1. open document in gedit and "save as" in different directory

Actual results:
The filename gets emtied and must be typed by hand

Expected results:
the file should stay as is

Does this happen every time?

Other information:
It seems to me as user (i am not a developer) this issue could be similar to:
Comment 1 Thilo Six 2007-03-18 14:51:32 UTC
This has been reported in ubtuntu:
Comment 2 Thilo Six 2007-03-18 14:55:29 UTC
Sorry it seems during bureporting something went wrong.
This wasn´t intend to go to deskbar-applet instead it should have gone to gtk+
Comment 3 Thilo Six 2007-03-18 15:05:34 UTC
ok i fixed that, bugreport is now bind to gtk+ 2.10.x
Comment 4 ntetreau 2007-03-20 17:11:02 UTC
Same problem here!
Comment 5 Thilo Six 2007-03-20 17:52:59 UTC
quote from ubuntu bug:
when editing in gedit an new file and try to save that it does not happen.

but when open an existing file and then repeat the above (save as) with double click on directory to view it´s content the filename is emptied.
Comment 6 Jaap A. Haitsma 2007-03-22 21:59:16 UTC
With me this does not happen in gedit. The only thing I can reproduce it is when double clicking on one of the items in "Places" just after the save as dialog has opened.  If I first double click on a folder and after that on Places the file n
Comment 7 Sebastien Bacher 2007-08-21 16:55:52 UTC
The Ubuntu bug has video of the bug using GTK 2.11
Comment 8 Sebastien Bacher 2007-08-21 16:58:54 UTC
*** Bug 461035 has been marked as a duplicate of this bug. ***
Comment 9 Sebastien Bacher 2007-08-21 16:59:32 UTC
*** Bug 450852 has been marked as a duplicate of this bug. ***
Comment 10 Sebastien Bacher 2007-08-21 17:00:15 UTC
*** Bug 434293 has been marked as a duplicate of this bug. ***
Comment 11 Sebastien Bacher 2007-08-21 17:00:41 UTC
*** Bug 429706 has been marked as a duplicate of this bug. ***
Comment 12 Milan Bouchet-Valat 2007-10-29 13:53:19 UTC
See bug 367427: the same when changing folder using Ctrl+L (for possibly further fix).
Comment 13 Federico Mena Quintero 2007-11-13 00:51:21 UTC
*** Bug 453383 has been marked as a duplicate of this bug. ***
Comment 14 Milan Crha 2007-11-22 12:34:38 UTC
*** Bug 495352 has been marked as a duplicate of this bug. ***
Comment 15 André Klapper 2008-01-03 01:09:44 UTC
*** Bug 494037 has been marked as a duplicate of this bug. ***
Comment 16 André Klapper 2008-01-03 01:18:52 UTC
copying from bug 494037:

Comment #5 from Christian Kirbach    (points: 23)
  I can confirm this with revision 19269 of gkt+ trunk
  it only applies to the "save as" dialog, not to the "save" dialog

Comment #6 from Benjamin Gramlich (points: 2)
  I get this behavior with gedit, but not with glade and firefox. Are we sure
  it's a gtk+ bug, and not a bug with applications that forget to track the

Comment #8 from Emmanuele Bassi (developer, points: 18)
  I've tried following the steps with gedit, epiphany and evolution, and I 
  cannot reproduce it.
  gtk+ 2.12.0 on ubuntu gutsy.

Comment 17 André Klapper 2008-01-03 01:23:45 UTC
it's definitely not an ubuntu-only bug, i also sometimes see that bug here on fedora7 with gtk2-2.12.1-5.fc8 installed.

i think it happens when there is already a "proposed" filename in the name field (starting with the same letters), not sure though.
Comment 18 Milan Bouchet-Valat 2008-01-03 10:44:45 UTC
I could reproduce it with Glade 3,, Anjuta.

But i could notice a strange thing with Glade 3: when you open a .glade file and then try to 'save as' it, sometimes the name of the file appears in the filechooser, and the file is selected, and sometimes not.

I could only see this instable behavior in Glade, but you can note that the other cited apps *don't propose you any name* when you choose 'Save As', but they used to, I guess, in precedent versions. When you switch to another folder using the Places panel,you can see for a quarter of second *the name of the file appear and disappear* (although it was not shown previously).

Looking at gedit code, I saw that it actually *sets a suggested filename*, which eventually doesn't appear:
doc = gedit_tab_get_document (tab);
	uri = gedit_document_get_uri (doc);

	if ((uri != NULL) &&
	    gedit_utils_uri_has_file_scheme (uri))
		uri_set = gtk_file_chooser_set_uri (GTK_FILE_CHOOSER (save_dialog),

I really don't know whether this is related, but it seems that something messy is going on here. Hope this helps...
Comment 19 Milan Bouchet-Valat 2008-01-03 10:59:44 UTC
Maybe I should precise a point: the subliminal filename occurs only in OO.o. There, a filename appears for a quarter of second at the moment the proposed filename disappears. OO.o is the only app I saw that always propose a filename that appears.

Moreover, I noticed a clue about the seemingly random behavior: if you work with a file saved in your Desktop folder, the file disappears when switching to you Home folder (at least). When you directly choose your Filesystem, no problem occurs. So at least there's some logic/regularity.

I can add that Abiword is a good example of behavior exactly like gedit (the proposed filename never appears). Good to compare.
Comment 20 Olle Bergkvist 2008-01-04 12:35:59 UTC
I've done some research, and it seems like there are several separate bugs, which we need to distinguish between. 

One bug is as mentioned in this bug report. FileChooserEntry is erased during TYPING in the tree view. That one seems to be fixed. Follow the link and see the patch from Jürg, which fixed it. 

That fix has nothing to do with this other bug, which is that some of us experience that the entry is erased when we GO TO another folder. 

I can tell you my results on Ubuntu 7.04 Feisty with GTK 2.10.11-0ubuntu3. I have installed kubuntu-desktop in addition to ubuntu-desktop, but of course i use GTK+ programs now and then. 

I do not have any problem when i TYPE IN THE TREE VIEW, so that seems to be fixed indeed. 

Usually, the following happens when i navigate to another folder: This applies to both Save and Save as dialogs. 
= The text in the file name entry gets highlighted. No problem at all. 

If i have set up the file name entry by clicking on a file (not a folder, a file), then 
= The file name is erased, as expected. The clicked file only exists in the current folder, so there is no point in keeping that file name in the entry. 

But, -- here comes the interesting -- , when i have written the file name in the entry by hand, sometimes under certain conditions (i am trying to found out what they are) this happens:
1. The text in that entry is set to the first file in the new directory
2. Lastly, after a few 0.1 seconds, the file name entry is erased. 
So this is similar to what Milan writes. 

Comment 21 Olle Bergkvist 2008-01-04 12:44:11 UTC
Created attachment 102109 [details]
Code to test GtkFileChooserDialog in a few ways

I think we should talk more about what results we get from different GTK+ code, and less about how this and that application works. If we read the source for some applications, maybe Gedit, then we can assure that they do use GtkFileChooserDialog and not some home-made widget, and that the problem isnt in their code, but in GTK+.
Comment 22 Olle Bergkvist 2008-01-04 12:56:32 UTC
Correction: I meant this instead:
1. The text in that entry is set to the first file in the OLD directory
2. Lastly, after a few 0.1 seconds, the file name entry is erased. 
Sorry for spamming the bug :/
Comment 23 Olle Bergkvist 2008-01-04 14:38:02 UTC
Ok. This is my first "draft" on what triggers the bug on my OS and my GTK+. 

If i 
1. navigate to a folder which has no subfolders
2. and type a file name in the entry
3. and then go to a folder in the Places list (a.k.a. Shortcuts)
then voila - it is erased!

This also happens if
1. the Save / Save As dialog is initialized with a current folder that has no subfolders
2. and the dialog is initialized with a file name, or i have typed a file name
3. and then go to a folder in the Places list (a.k.a. Shortcuts)

That might explain why some of us always are affected by the bug, while others are not: The affected users have no subdirs in the directory where they save their files!
That might also explain why many users says it only affects Save As but not Save new document: The new document is saved in their home directory or some other "general purpose" directory where they have a lot of subdirs. 
Save as saves in the folder where the original document is, which may be a bottom level directory. 

So, my hypothesis is that this bug (as described here) is always present, but not everyone notices. 
This seems reasonable, doesnt it? :)
Comment 24 Olle Bergkvist 2008-01-05 02:49:21 UTC

The bug (the one i described above) has another criteria to happen. 
1. navigate to a folder which has no subfolders
-- and do NOT click in the file listing to select one of the files --
2. and type a file name in the entry
3. and then go to a folder in the Places list (a.k.a. Shortcuts)

This leads me to think that when i have not selected any file, then the file chooser selects a file (the first one in the list) by mistake, BEFORE the files are replaced with the files in "the Places directory i enter" ("target directory"). 

And whenever a file in the list is selected, the text in the Text Entry is replaced with this file's file name, as intended. This can be seen for a very short while in the text entry. 
And a few 0.01 seconds later, when the file chooser switches to the "target directory", 
because the text entry holds a name of a file in the previous directory, it is erased, as intended. 

Right now I'm digging in the source file gtkfilechooserdefault.c and trying to locate the source of the focusing problem. 

Comment 25 Olle Bergkvist 2008-01-05 07:03:47 UTC

I found the exact cause of the problem. 
Right now i'm too tired, my hands are shaking, and i'm running off a  Live CD, so i wont explain what caused the bug now. 

But Sunday or the beginning of next week i will write a fix, try it, and apply it to SVN or whatever is the correct procedure.

Comment 26 André Klapper 2008-01-05 12:24:11 UTC
Olle, thanks a lot for your investigations!
Comment 27 Jaap A. Haitsma 2008-01-05 12:31:58 UTC
Olle. Great. Normal procedure is that you attach the patch to this bug. The maintainers will review it and apply it
Comment 28 Milan Bouchet-Valat 2008-01-05 13:52:03 UTC
2008-01-05 02:49 UTC - 2008-01-05 07:03 UTC What a nice night! Well, good work, if you get the right patch you will save a few thousands of users - you deserve a GTK+ medal! ;-)
Comment 29 René Stadler 2008-01-05 15:09:24 UTC
FWIW, I reported some possible fix as part of bug #453383 many months ago.  The problem with fixing this proper is that the right person has to step up -- the file chooser is a _very_ large and complex piece of code.
Comment 30 Olle Bergkvist 2008-01-06 03:22:36 UTC
Thanks for all the nice feedback. Work goes on, maybe i will send a patch tomorrow (sunday). 

Milan: An interesting night indeed! =)

René Stadler: FWIW, Sorry to say this, but i don't think your fix is a good long-term solution. It just inactivates the focusing instead of making it work as intended, which i am trying to do. 
And i highly doubt it is as difficult as you say to modify gtkfilechooser. After all, i am doing it, and i'm in no way any expert. 

Maybe this is the wrong place to ask, but what version of GTK+ should i patch? Are there several branches i can patch? From which source should i download it?

Right now i modify 2.10.14, but i realize there are much newer versions that should be patched in first place. 
Comment 31 André Klapper 2008-01-06 10:35:41 UTC
@Olle: 2.12.3 is the latest stable release and would be a good target, same with gtk+'s svn trunk in GNOME svn (the "2.13.x" version, but there has not been a release yet). the patch has to go into trunk and the 2.12 branch, so do just as you like... :)
Comment 32 René Stadler 2008-01-06 11:26:36 UTC
Olle: If I had been sure that the fix was right I would have just posted a patch.  The pointer to the code line was meant to ring the bell of some core developer (a.k.a. someone who could get a solid fix without spending hours or even days getting familiar with this large code base first).  After all, there is someone who introduced the bug at some point.

Whatever; it seems that the right people are on track to get this fixed now.  Rock on, Olle!
Comment 33 Olle Bergkvist 2008-01-10 15:57:09 UTC

I have not worked on the fix this week, except for a short while on monday, but today, finally, i had possibility to fix it. I think i now have a pretty reliable fix and i hope it's not just something that "works for me". 

Of course i dont know if the problem with the erased file name will happen again, but at least i have fixed one of the causes :)

As i said i fixed 2.10.14. The SVN trunk won't even build because i have too old Pango etc. I won't try to fix that :/

Since i have already looked at SVN trunk code, and svn seems excellent for diffing, i might patch the trunk instead of my old version. But that requires that someone of you test the patch for me. 
Comment 34 André Klapper 2008-01-10 16:25:29 UTC
great news! Olle, can you please attach a diff here (for 2.10.14 or whatever you like :-) so others can also test it? thanks!
Comment 35 Olle Bergkvist 2008-01-10 17:07:52 UTC
Created attachment 102528 [details] [review]
Patch (diff -ru) to fix Bug 419737 on GTK+ 2.10.14

This is The Patch that works for me and seems pretty reliable. I have installed a GTK+ build with this patch, so if there is any bugs in it i will notice that.
Comment 36 Olle Bergkvist 2008-01-10 17:14:03 UTC
Created attachment 102529 [details] [review]
Patch (svn diff) to fix Bug 419737 on current GTK+ trunk

This is my guess of how a patch for the trunk may look. I can't build the trunk, so i don't know if this patch works or not.
Comment 37 Olle Bergkvist 2008-01-10 21:13:58 UTC
Created attachment 102543 [details] [review]
updated patch for 2.10.14

It seems the patches had a few errors. Here a two updated patches. 
I still cannot know if the patch for the SVN trunk works or not.
Comment 38 Olle Bergkvist 2008-01-10 21:18:19 UTC
Created attachment 102544 [details] [review]
updated patch for updated SVN trunk
Comment 39 Olle Bergkvist 2008-01-11 14:34:02 UTC
No feedback yet? Won't you test the patches?

When you test the SVN patch, make sure you test in Open mode as well, and with the file name entry hidden (in Open mode...)

Needless to say, look out for g_assertions on stdout and other indications of errors. 

Comment 40 Emmanuele Bassi (:ebassi) 2008-01-11 16:06:15 UTC
(In reply to comment #39)
> No feedback yet? Won't you test the patches?

thanks for the patch, Olle. don't worry: the patch is now in bugzilla, and won't be lost. just have patience: gtk+ maintainers will look at it, even though it might take some time.
Comment 41 Marius Gedminas 2008-01-11 22:10:57 UTC
I can reliably reproduce this bug with the Save As dialog in Firefox or gedit.  It seems to be timing-related: if I click on a place that has few files in it, the location entry is preserved, but if I click on a place that has a few hundred of files in it, the location entry gets erased, after a short delay.

The patch against SVN trunk applies cleanly to Ubuntu's gtk+ 2.12.0 and fixes the problem for me.

Thank you, Olle!  This bug was very annoying.
Comment 42 Michael Chudobiak 2008-01-21 13:40:10 UTC
*** Bug 510517 has been marked as a duplicate of this bug. ***
Comment 43 Michael Chudobiak 2008-01-21 13:41:03 UTC
*** Bug 497074 has been marked as a duplicate of this bug. ***
Comment 44 Olle Bergkvist 2008-01-24 11:25:47 UTC
The SVN patch needs some redesign i think... It completely changes a function it probably shouldn't touch. Give me some time and i will rewrite it. I know the deadline of 30 Jan. 
Comment 45 Olle Bergkvist 2008-01-28 22:39:07 UTC
Created attachment 103917 [details] [review]
updated cleaner patch for SVN trunk

This patch is an alternative for the previous patch for SVN. It creates a new function "focus_browse_tree_view_if_location_bar_unchanged" to avoid confusion with the old function "focus_browse_tree_view_if_possible".
Comment 46 Olle Bergkvist 2008-01-28 22:41:05 UTC
Just to clarify a bit, it didn't take me 4 days to write this 3KB patch ;) I have been busy IRL. 
Comment 47 Sebastien Bacher 2008-02-05 12:05:07 UTC
could somebody review this patch? the issue is a common user complain
Comment 48 Federico Mena Quintero 2008-02-05 19:53:17 UTC
*** Bug 483277 has been marked as a duplicate of this bug. ***
Comment 49 Federico Mena Quintero 2008-02-05 23:22:43 UTC
Created attachment 104525 [details] [review]

Thanks for working on this patch, Olle :)  You had to go into some of the nastiest corners of the file chooser, so you can now show your scars with pride.

For some stupid reason, a long time ago I decided that activating a shortcut should cause the file chooser to focus the file list.  However, this plays badly with single-click shortcuts (bug #148828) and is a weird idea in general --- I had intended it to work that way for keyboard navigation, but it creates more problems than it solves.

The patch I've committed to SVN is much simpler:  it simply makes the shortcuts pane not activate the file list at all.  Using the file chooser now feels smoother, and it no longer clears the filename entry at the wrong time.

This is now in gtk-2-12 and trunk:

2008-02-05  Federico Mena Quintero  <>

	Don't focus the file list when shortcuts get activated.  This
	removes a lot of ambiguity in when the file selection should
	change, and makes the overall code flow simpler.

	This fixes -
	file/save dialog clears the filename entry when changing

	Also fixes -
	focus should not go to the file list when a shortcut is activated.

	* gtk/gtkfilechooserdefault.c
	(shortcuts_activate_volume_mount_cb): Don't focus the file list
	(shortcuts_activate_get_info_cb): Likewise.
Comment 50 Philipp 2008-02-06 11:01:38 UTC
Thank you so much Olle for finding the cause of this, and thanks Federico for even coming up with a simple fix. :-)
Comment 51 Olle Bergkvist 2008-02-06 20:32:01 UTC
Federico: Shouldn't you change the third and last function calling focus_browse_tree_view_if_possible too?

If you look in my patch there are three such functions, and i _think_ that they all cause the same problem with the erased file name. 

Comment 52 Federico Mena Quintero 2008-02-12 19:20:08 UTC
(In reply to comment #51)
> Federico: Shouldn't you change the third and last function calling
> focus_browse_tree_view_if_possible too?

At first I thought we should leave the call in that last place, as it's where the keyboard shortcuts for "go to home" or "go to desktop" get used.

But now I think you are correct... if you are in the filename entry, you don't want the focus to go to the file list if you hit one of those shortcuts.  Example:  You type "newfilename.txt" in the location entry and then you hit Alt-Home to change to your home.  You want the focus to remain in the location entry, not to switch to the file list.

I'll commit a change to do this.  Thanks for checking the patch! :)
Comment 53 Federico Mena Quintero 2008-02-12 19:34:53 UTC
Created attachment 105080 [details] [review]

This is now in gtk-2-12 and trunk.  I had forgotten to commit the previous patch to trunk as well (oops!); it's now there.

2008-02-12  Federico Mena Quintero  <>

	* gtk/gtkfilechooserdefault.c (switch_to_shortcut): Don't focus
	the file list (this was the last place where we would focus the
	file list explicitly).  If you are in the location entry, for
	example, you don't want Alt-Home to take you to the file list; you
	just want the current folder to change.  Thanks to Olle Bergkvist
	<> for pointing this out in
	(focus_browse_tree_view_if_possible): Removed.
Comment 54 Federico Mena Quintero 2008-02-26 23:03:20 UTC
*** Bug 355756 has been marked as a duplicate of this bug. ***
Comment 55 Mattias Eriksson 2008-03-28 16:10:17 UTC
I would not say that this is fully fixed... I can still reproduce this kind of behaviour using libgtk2.0-0            2.12.9-2ubuntu1.

To reproduce:
Open a text file on the desktop using gedit
Save As
Then klick on the homefolder in the location bar or some folder in your shortcut bar. 
This will cause the filename to go away. 

It now works if you first select a subfolder in the save dialog, and after that you can click in the location bar and short cuts without loosing the filename.
Comment 56 Milan Bouchet-Valat 2008-06-14 12:54:50 UTC
Confirmed case. Please absolutely reopen this bug.
Comment 57 Murray Cumming 2008-06-14 14:00:04 UTC
Reopened. I think you can reopen bugs yourself.
Comment 58 Milan Bouchet-Valat 2008-06-14 14:32:28 UTC
I wish I could, but as none of us was the original reported, we were denied to do so. ;-)
Comment 59 Olle Bergkvist 2008-06-15 11:16:24 UTC
Ok i finally took the time to try this out again. Federico's fix has indeed been pushed to the repositories of my distro, and the original bug is not there. When writing a custom file name it's NOT erased. What you're talking about is an entirely different thing. When clicking/writing a filename of a file that exists in the current directory (or loading a dialog that has a file name pre-set), and going to another directory, then the file name is removed. Please fork this bug report into a new one, talking about this other bug. Feel free to fork also this comment of mine. -_-

What happens in this other bug is that when going to a new directory, the text in the file name box is compared to the name of the file that was last highlighted in the browser. If they are the same, then it is erased. 
The stupid assumption is made that this file will only exist in this particular directory. So when going to another dir, it's erased. 
This works pretty well with Open mode. But definitely not with Save (As) mode. 
It is a feature that's pretty intentional, though i'm not sure the devel who added it knew what he was doing. 

So yes, it's a bug, but it's another bug. And people are not careful enough to find out exactly how their bug behaves ;)

I still remember reading the code for this misfeature, I could still fix it. If you GTK+ devels want, i could remove the feature or set it to be present only in Open mode. Just tell me to do that and i'll attach a patch in a couple of days. 
Comment 60 Milan Bouchet-Valat 2008-06-15 11:19:52 UTC
Since symptoms are quite similar, I don't see the point of opening a new report. Just continue here. Thanks for your investigation!
Comment 61 Olle Bergkvist 2008-06-15 11:48:10 UTC

I tried this in KDE's file chooser now, and it turns out they erase the file name as well. But, only in Open mode, not in Save mode. 

Would that be the best solution for us, or would it be to remove this feature altogether?
Comment 62 André Klapper 2008-06-15 12:46:33 UTC
Olle: Thanks for your investigations! Interesting in coming up with a patch?
Comment 63 Olle Bergkvist 2008-06-15 13:36:04 UTC
Andre, I still need a answer to my question: 

> This works pretty well with Open mode. But definitely not with Save (As) mode. 

> I tried this in KDE's file chooser now, and it turns out they erase the file
name as well. But, only in Open mode, not in Save mode. 

> Would that be the best solution for us, or would it be to remove this feature altogether?

So, when should we erase the file name from the text box? Never? Only in OPEN mode? 
Comment 64 Olle Bergkvist 2008-06-17 14:21:35 UTC
Ok I have a bunch of patches, some of which for the beforementioned bug, and some of them for other bugs I discovered in the process. 

There are at least two different pieces of code that clears the file name entry upon changing directory. 
First to be called is shortcuts_activate_iter line 10231. 
That one is called when clicking on a shortcut or otherwise navigating to a folder that is shortcut. It clears the entry if we are not in SAVE mode. 
Second is update_chooser_entry line 6783. It is called if we go to a folder by any method. It clears the entry if the text in the entry is the same as the name of that last clicked file. (Well, almost, see new bug below. * )

The first one should let CREATE_FOLDER mode fall through as well. One patch for that. 

The second one should let SAVE and CREATE_FOLDER modes skip the check, antoher patch for that. 

* New bug: The reason that not even in OPEN mode is entry cleared upon entering a subfolder is that the value of the last selected file gets fscked up when clicking the subfolder. The chooser doesn't know it's going to be a double-click but acts like it's a single click. So, it looks to the chooser like a custom file name and it's preserved. 

*Newer bug: When (double-) clicking a folder in CREATE_FOLDER mode, the entry should be preserved, so that the user can go to subfolder without resetting the entry. Oh well. This is getting longwinded. 

A new dilemma is: What to do with those both old maybe-clear-entry checks? If the only criteria should be whether we're in SAVE/CREATE or in OPEN/SELECT mode, then it should all be simplified. At least the sc_activate_iter one should be removed. And the one that's left should be changed to reflect that the only thing that matters is the MODE. 
Comment 65 Olle Bergkvist 2008-06-17 14:24:19 UTC
Created attachment 112910 [details]
New Test Case

This is a test case I've been using. Someone on IRC requested it, so here it is. It tries all file chooser modes i can think of.
Comment 66 Olle Bergkvist 2008-06-17 14:32:02 UTC
Created attachment 112911 [details] [review]
Fixes the main problem, file name check, SAVE mode

This fixes the main problem that people usually complains about. It skips the check in SAVE mode (and also CREATE_FOLDER mode) whether the entry is the latest focused file, and leaves the entry untouched. 

These new patches do NOT have anything to do with, or obsolete, the older patches already committed. They are all for separate bugs.
Comment 67 Olle Bergkvist 2008-06-17 14:34:44 UTC
Created attachment 112912 [details] [review]
Fixes an additional entry erasing problem in CREATE_FOLDER

When a shortcut is activated, don't clear the chooser entry in CREATE_FOLDER mode either.
Comment 68 Federico Mena Quintero 2008-06-18 22:27:48 UTC
Thanks for tracking this down, Olle :)  I've committed your patches to trunk and gtk-2-12.

2008-06-18  Olle Bergkvist <> - The file
	chooser clears the filename entry in SAVE/CREATE_FOLDER modes when
	it shouldn't.

	* gtk/gtkfilechooserdefault.c (shortcuts_activate_iter): Don't
	clear the entry for CREATE_FOLDER either; this needs the same
	behavior as SAVE mode.
	(update_chooser_entry): Only clear the entry in OPEN/SELECT_FOLDER

Comment 69 Olle Bergkvist 2008-06-19 21:47:59 UTC
Federico: You asked me when I thought the entry should be cleared. So I thought I'd write something here. 

This patch fixes the inconsistency that incorrectly sets last_selected_name, and therefore the entry will be cleared depending on the check in update_chooser_entry, the label maybe_clear_entry, line 6735 and onwards. 
Two functions: 
update_chooser_entry : maybe_clear_entry: line 6735

The first clears entry on SELECT and OPEN. 
The second clears only in SELECT and OPEN, if the file name test (maybe_clear_entry:6735) passes. 
We could keep both. That could be confusing for the user, and shortcuts_activate_iter would "bypass" the filename test in maybe_clear_entry. 
We could get rid of the entry clearing in shortcuts_activate_iter and keep the other. 
We could get rid of both and always clear the entry in OPEN/SELECT in update_chooser_entry or somewhere else. 
That would be the way KDE behaves (in OPEN mode). That's my choice. It's simple and predictable for the user.