The save as dialog currently has a history dropdown menu that just remembers the history of directories browsed during the current save as interaction. This should be changed to contain a persistent list of the last N directories where files have been saved to. This is a very important and convenient features since users often save different types of data (html, images, postscript) to entirely different local directories. For a quick solution i propose N to be 6 and a temporary sorted list in the drop down (most recent first).

*** This bug has been marked as a duplicate of 115574 ***

sorry, not the same. The other bug is an All bug filed by a windows user. This bug, filed per my request, I must note, is for the XP filepicker to support this functionality, which is a totally separate kettle of fish. I should also note that the current dropdown has no history in it anymore, it just has the ancestor list. Mpt, I'm not sure whether it would be better to have a separate dropdown for the recent dirs or whether I should put them in the ancestor list dropdown (with a separator before them, of course). Thoughts?

Gonna try to get to this for 1.0.

BZ: No problem.. Removing myself from CC

I think there should be seperate lists: it is semantically clearer, each list will be shorter, also the list of recent dirs has a limited number of entries whereas the ancestor list is fairly unlimited (is there a limit to directory nesting?). The problem when having it in one list: if the ancestors come first, one might have to scroll down an unknown, possible large number of entries to find a recent dir. If it is the other way round, simply going up one level becomes extremely clumsy.

discussion and proposals for the enhancement of filepicker are in bug http://bugzilla.mozilla.org/show_bug.cgi?id=125133

No time to work on this for 1.0. Adding helpwanted keyword. If you want to work on this, please let me know and I can give some pointers...

*** Bug 102877 has been marked as a duplicate of this bug. ***

very rough proof-of-concept patch in case people want a jumping-off point. Issues with this patch: 1) The recent dirs list should be a menubutton with an image (a la bookmarks button on personal toolbar), not a menulist. 2) Pref observers are needed. If multiple filepickers are open and a file is picked in one, the others need to update the recent dirs list 3) The "number of things to save" may need to be made non-prefable. This would significantly simplify the code assuming we picked one value and never changed it. 4) For open/save we should remember the _file_ not the directory. Selecting that file from the list should go to the correct dir and select the file in the outliner (but not trigger ok).

Boris, I have already taken first steps to include your code in the new filepicker stuff I am working on in bug 125133. Here a few comments: 1) the design in attachment 72579 [details] originally planned to have the recent files in the "look in" menulist instead if the ancestor list. The ancestor list would be moved to the dropdown list that is attached to the "up" button, where it seems to belong naturally. The dropdown list near the home button should eventually contain a list of bookmarked (favorite) directories. I wouldnt know a good and intuitive way to design two different buttons, one for the MRU directories and one for the favorite/bookmarked ones ... 2) why do we need pref observers when the filepicker dialog is modal? no two of them seem to be able to exist at the same time anyway. OTOH I am the first to support getting rid of modal dialogs, so could you point me to an example js where pref observers are used? 3) I think having this just as a hidden pref for now wouldnt be that complicated? I think ultimately, the dropdown menu should have two "special options", set apart by a separator, that allow to clear the list and maybe pick the number of dirs to remember (though the latter is not that important) 4) I really dont see the advantage of this and I think it would make things harder to implement and harder to understand by the user. Also it would work differently from MRU dir menues in other programs, and thus be confusing.

> the design in attachment 72579 [details] originally planned to have the recent files > in the "look in" menulist instead if the ancestor list. The ancestor list > would be moved to the dropdown list that is attached to the "up" button, > where it seems to belong naturally. The "ancestor list" is a dropdown from the current directory in every application I have looked at which has an ancestor list. People depend on this behavior and we should follow it... > I wouldnt know a good and intuitive way to design two different buttons, > one for the MRU directories and one for the favorite/bookmarked ones ... Me neither, but that's the part at which we ask a UI design person to help... :) > why do we need pref observers when the filepicker dialog is modal? Because filepicker should be _window_-modal. That is, filepicker in one window should not freeze other windows. The fact that it does is a but in the toolkit code which will get fixed at some point... You can open multiple filepickers with Ctrl-O as it is (due to yet another bug in event code). Pref observers are used in, say, navigator.js (search for addObserver/removeObserver). My current code is kinda sucky since it's not clear what one should observe... > I think having this just as a hidden pref for now wouldnt be that > complicated? Well, it makes the code complicated because making that number smaller involves trimming off the extra prefs and such.... Hence the branch-clearing hack. > clear the list Hmm.. sure, if we feel that's needed.... Let's not overcrowd the UI here. :) > pick the number of dirs to remember This is one of those "if this is pref-able at all, it should not have UI" things, imo. Again, let's not clutter up the UI with things only about 10 people will ever use. > I really dont see the advantage of this and I think > it would make things harder to implement and harder to understand by the user. > Also it would work differently from MRU dir menues in other programs, That's because it's not an MRU _dir_ menu, it's an MRU _file_ menu. See, eg, what MacOS itself or Word have -- list of most recent files you have worked with. The advantage is that users tend to open the same _files_ over and over (the ones they're working with). This is for modeOpen. For modeSave and modeSelectDir I think storing the directory itself is better (yes, I know that's not what point 4 said; I have thought about it more since then). Again, we may want UI design's feedback on this stuff. Thanks for working on this stuff, Johann. :)

Hmmm well, I think that there is not that much reason from a usability point of view to give the ancestor list such an importance except that obviously it is easiest to implement (e.g. KDE apps usually have a recent dir list instead). I have looked at quite a few apps on my machine and there is not much standardization here. However the GTK filepicker is pretty common, but IMHO it is *very* badly designed. The ancestor list IMO logically belongs to the up button -- I later found out that StarOffice has adopted a similar solution. Staroffice in addition to the up button with the ancestor list also has a "default dir" (not home dir) button that has a menu attached with both recent and bookmarked dirs, but recent dirs are too hidden there. I am all for standards and not puzzling users, but certainly Mozilla should be better where there is room for improvement .. .:) I'd sure be glad to hear opinions of UI people here (even though I believe that I do have some experience when it comes to UI design and usability issues ) OK, filepicker should be window modal, agreed, we need pref observers .. I too dont want to overcrowd the UI, thats why I came up with that idea of double-using up and home buttons in the first place. However I foresee that people will complain about not being able to clear the MRU list out of security and privacy reasons (not as big an issue as on single-user OS, but still people might share users on a linux machine) Anotehr thing is that both the recent and the favorite dir menu would have a separated "section" of options for managing the entries. I think that fits quite nicely with the interface people are used to when using the bookmark menu. But of course we can postpone this for simplicity. Agree to have N be a hidden pref, if at all. I agree that for open it could make sense to remember files instead of dirs, but it makes the semantics of this a bit inconsistent. We would also have to change the text "recent dirs" to "recent files" dynamically. Another thing is that opening ten different files from a single dir will make go away the other *dirs* from which files were recently opened. My understanding was that the purpose of the MRU dir list was to a great extend to cut down the number of clicks needed to navigate to some "distant" directory. I often open files from N different dirs (e.g. work, fun, tmp) on different file systems so personally I would prefer that. OTOH if we also have favorite dirs (e.g. folder bookmarks), that need vanishes because the user can just bookmark his favorite folders.

1.1alpha is frozen. Unsetting milestone and will retriage in a few days when I can make a realistic assessment of the situation.

no time to work on this. Really helpwanted now.

A couple of issues I am still not sure of: Should we remember different sets of files/dirs for the different modes? Do we want this to remember recent files or recent dirs, and which for which mode? Where should that functionality be located in the GUI? I addition to my suggestion to add this as a menu-button to the "up" button there is another option: Change the filename text entry field into a editable menu list. The advantage of the latter is that it is located "closer" to the field that is active per default and hence can be activated much easier using the keyboard.

I have no plans to continue work on this... someone else will need to step up. :(

*** This bug has been marked as a duplicate of 24625 ***