GNOME Bugzilla – Bug 419737
File save dialog deletes/empties filename when changing directory
Last modified: 2008-06-19 21:47:59 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 2. 3. 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? yes Other information: It seems to me as user (i am not a developer) this issue could be similar to: http://bugzilla.gnome.org/show_bug.cgi?id=308332
This has been reported in ubtuntu: https://launchpad.net/ubuntu/+source/gtk+2.0/+bug/93396
Sorry it seems during bureporting something went wrong. This wasn´t intend to go to deskbar-applet instead it should have gone to gtk+
ok i fixed that, bugreport is now bind to gtk+ 2.10.x
Same problem here!
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.
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
The Ubuntu bug has video of the bug using GTK 2.11
*** Bug 461035 has been marked as a duplicate of this bug. ***
*** Bug 450852 has been marked as a duplicate of this bug. ***
*** Bug 434293 has been marked as a duplicate of this bug. ***
*** Bug 429706 has been marked as a duplicate of this bug. ***
See bug 367427: the same when changing folder using Ctrl+L (for possibly further fix).
*** Bug 453383 has been marked as a duplicate of this bug. ***
*** Bug 495352 has been marked as a duplicate of this bug. ***
*** Bug 494037 has been marked as a duplicate of this bug. ***
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 current_name? 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.
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.
I could reproduce it with Glade 3, OpenOffice.org, 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: (from http://svn.gnome.org/viewvc/gedit/trunk/gedit/gedit-commands-file.c?view=markup) 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), uri); } I really don't know whether this is related, but it seems that something messy is going on here. Hope this helps...
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.
I've done some research, and it seems like there are several separate bugs, which we need to distinguish between. One bug is http://bugzilla.gnome.org/show_bug.cgi?id=308332 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.
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+.
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 :/
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? :)
Update. 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.
Success. 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.
Olle, thanks a lot for your investigations!
Olle. Great. Normal procedure is that you attach the patch to this bug. The maintainers will review it and apply it
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! ;-)
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.
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.
@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... :)
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!
Fixed. 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.
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!
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.
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.
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.
Created attachment 102544 [details] [review] updated patch for updated SVN trunk
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.
(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.
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.
*** Bug 510517 has been marked as a duplicate of this bug. ***
*** Bug 497074 has been marked as a duplicate of this bug. ***
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.
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".
Just to clarify a bit, it didn't take me 4 days to write this 3KB patch ;) I have been busy IRL.
could somebody review this patch? the issue is a common user complain
*** Bug 483277 has been marked as a duplicate of this bug. ***
Created attachment 104525 [details] [review] gtk-filechooser-dont-focus-file-list.diff 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 <federico@novell.com> 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 http://bugzilla.gnome.org/show_bug.cgi?id=419737 - file/save dialog clears the filename entry when changing directories. Also fixes http://bugzilla.gnome.org/show_bug.cgi?id=499940 - 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.
Thank you so much Olle for finding the cause of this, and thanks Federico for even coming up with a simple fix. :-)
Federico: Shouldn't you change the third and last function calling focus_browse_tree_view_if_possible too? If you look in my patch http://bugzilla.gnome.org/attachment.cgi?id=103917 there are three such functions, and i _think_ that they all cause the same problem with the erased file name.
(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! :)
Created attachment 105080 [details] [review] gtk-filechooser-dont-focus-file-list-shortcut.diff 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 <federico@novell.com> * 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 <olle.bergkvist@yahoo.se> for pointing this out in http://bugzilla.gnome.org/show_bug.cgi?id=419737#c51. (focus_browse_tree_view_if_possible): Removed.
*** Bug 355756 has been marked as a duplicate of this bug. ***
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.
Confirmed case. Please absolutely reopen this bug.
Reopened. I think you can reopen bugs yourself.
I wish I could, but as none of us was the original reported, we were denied to do so. ;-)
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.
Since symptoms are quite similar, I don't see the point of opening a new report. Just continue here. Thanks for your investigation!
Ok. 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?
Olle: Thanks for your investigations! Interesting in coming up with a patch?
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? Thanks
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.
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.
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.
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.
Thanks for tracking this down, Olle :) I've committed your patches to trunk and gtk-2-12. 2008-06-18 Olle Bergkvist <olle.bergkvist@yahoo.se> http://bugzilla.gnome.org/show_bug.cgi?id=419737#c59 - 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 modes.
Federico: You asked me when I thought the entry should be cleared. So I thought I'd write something here. This http://bugzilla.gnome.org/show_bug.cgi?id=539188 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: shortcuts_activate_iter 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.