OS: All except for Windows :-) Since GTK filepicker doesn't seem to get good enough anytime soon, we need to make the current XP filepicker usable. Mozilla for OS's other than Linux would also gain much in terms of convenience. Two convenient features needed in a filepicker are: 1. Configurable directory bookmarks for navigation to frequently used directories (eg. user's home directory, various document directories) 2. "Create new directory" button An already existing filepicker that is closest to my ideal is the KDE filepicker (I'll attach screenshots that show it in action). It offers directory bookmarks (they are flat, though, instead of hierarchical) and a button for creating new dirs. Also, Windows Commander has the most excellent directory bookmarks functionality I've ever seen - similar to Mozilla's webpage bookmarks, it's hierarchical, offers ability to set titles of dir bookmarks and a well-designed bookmarks editor. I'll atttach screenshots from Windows Commander too. Would it be possible to use Mozilla's current webpage bookmarks code for directory bookmarks? I would imagine dir bookmarks button would work just like the "Bookmarks" button on the Personal Toolbar, showing a hierarchical menus with submenus and would handle drag and drop reorganization of dir bookmarks properly. Drag and drop is currently broken for webpage bookmarks, but hopefully will get fixed. See bug 64768, bug 19437, bug 50505, bug 105263 and possibly bug 93590. If properly implemented, resolution for this bug would make most of claims of bug 80636 obsolete, so I'm going to make 80636 dependent on this bug.

The shortcut for dir bookmarks in Windows Commander is CTRL-D.

marking p5 and future

->bryner

Making this bug depend on bug 19437 (as directory bookmarks will most probably be based on webpage bookmarks).

Why are these two items combined into one bug? We already have bug 58311 for adding a "create directory" button.

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

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

I should note that just typing a path to a file that includes nonexistent directories should work, since nsLocalFileUnix::Create() will create ancestors as needed and the filepicker is smart about only checking that the first _existing_ ancestor of the file you want to save to is writable. Discoverable it is not, but usable it is.

bug http://bugzilla.mozilla.org/show_bug.cgi?id=125133 has some discussion and proposals for and enhanced filepicker

Johann: the design from bug 125133 comment #33 looks very good indeed. My only complaint, there are no user-editable hierarchical directory bookmarks, but a history of recent dirs is easier to implement and will suffice for most cases. Directory bookmarks and editor for them may be added in the future as an alternative way to navigate to frequently used dirs.

The issue is how to make the GUI clear enough that the user knows what is the list of MRU dirs and what are the bookmarks, and how to find a compromise between fast and easy usability of the bookmarks and a full fledged bookmark functionality that allows the user to do everything he can think of. The bookmark facility I suggest is intended to be easy to use, yet provide most of the functionality: the dropdown allows to add the current dir to a list of bookmarks that can contain 10 (or N) bookmarks max. Adding more will result in the oldest one to be discarded. For security reasons it should be possible to clear the list of both bookmarks and MRU dirs with some function in the preference dialog. BTW, the solution for the bookmarked dirs is derived from what KDE does but enhanced by the thought of regarding the home dir as the "most important default" bookmark. I think this is what 99% of the users will need. Always interested in better solutions that still dont get excessively complicated and dont clutter the dialog too much, tough :)

Sounds reasonable. Although, a fixed size of 10 elements for bookmarks may be a drawback... For me it will be. Still, it's what will suffice for 90% of users :)

I just stumbled over the solution StarOffice 5.2 / linux has for this: There is a bookmark/home icon that has an associated drop down menu with bookmarked folder (and some predefined favorites). The top portion has an "add folder bookmark.." entry for folders that are not yet bookmarked. This brings up a dialog where a name for the bookmark can be given. If the user currently is displaying a fodler that is in the bookmark list, the option "remove folder bookmark xxx" appears. If the list of bookmarks is not empty, the entry "edit folder bookmrks" is shown. The edit folder bookmarks dialog allows more flexible editing of the bookmark list. I think a solution similar to that would be optimal in the long run. I'll be looking into what would be necessary to implement this.

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

"Create new directory" is bug 58311. Most or all of the dups of this bug are really dups of bug 58311. I think a "recent folders" dropdown (bug 125210) would make more sense than user-configurable "directory bookmarks". Wontfix?

Jesse, 115981 is also about favorite/bookmarked dirs. I plan to work on that eventually when I have a bit of time on my hands and I am done with 58311. See the proposed layout in 125133, attachment 75569 [details]. So this bug should probably just be a DUP of 115981?

Re comment #20: this is not a dup. Bug 115981 is for the inclusion of favorites to the Windows native filepicker, this one is for the XP filepicker. Adding dependencies.

Raising some issues: 1) I have currently two ideas how to add bookmarks to the filepicker dialog: a) make the home button a button of type "menu-button": this would add dropdown arrow to that button - clicking the home button would go to the home directory, clicking the dropdown array on its side would open the favorites menu. Advantage: UI not cluttered with another button, there is also a nice logical connection between the two, since "home" can be regarded as a kind of "default" and most often used favorite folder. b) adding a new button just for the favorites that will open the favorites menu. Advantage: will be more clear and obvious where to find the bookmarks. 2) how many favorites should we support, for how many should this function be optimized? Using the preferences as a place to store the favorites will probably become impractical for more than, say 10 of them. On the other hand, using a seperate external RDF file or something similar might slow down the whole filepicker dialog in an undesirable way? 3) Should we just remember the directories (as in KDE) or let the user add a description (as in URL bookmarks). If we add descriptions, whould we allow hierarchical bookmarks, grouped by description? 4) which functions should be supported? Clearly there should be an "Add this directory" as in KDE. However KDE doesnt check whether the directory already is in the favorites list, nor does there seem to be a way to get rid of them or reorder them. Any "Edit favorites" function would be largely dependant on the answers to points 2 and 3. My personal suggestion would be to just remember directories, allow an arbitrary number, allow descriptions which default to directory names, show only descriptions in the menu, and keep the edit dialog as simple as possible.

Another issue is if favorites should be different or same for the different modes (opening file, opening dir, saving file) of filepicker. I would suggest to have the same favorites for all modes.

Incorporation by reference: http://bugzilla.mozilla.org/show_bug.cgi?id=24625#c13 http://bugzilla.mozilla.org/show_bug.cgi?id=24625#c15

mrmazda, I dont see your point, care to explain? Please note that the issue of being used to a specific filepicker (e.g. the OS/2 one) versus making a new one that will be useful and acceptable for as many people as possible who might be used to completely different filepickers (e.g. gnome, Windows, or KDE) always must be handled with some pragmatism. Instead of assuming that all other OS should use exactly this filepicker it would be helpful to tell which of its features might be superior, and why. And please keep this ontopic, i.e. on the topic of folder favorites/bookmarks.

This is really a meta issue. The other comments explain, but since that wasn't good enough for you, here it is again: Instead spend the effort creating a GPL multiplatform filepicker (or port XFile from OS/2) with all the desirable features and provide that instead of building a custom filepicker into each app, such as Mozilla, Galeon, OpenOffice, Smartsuite, etc. That way, only graphics apps might need a custom filepicker, and all others would have a consistent interface. Features include: 1-Button for last accessed locations (configurable history length; miminum 10) 2-Button for last accessed files (configurable history length; minimum 10) 3-Button for favorite locations (easily configured; might need a cap at 50 or 100) 4-Quick (direct/nearly direct) access to other locations and files 5-Memory of last chosen file type as default (but configurable) 6-Remembered and/or fixed by user window size (itty bitty select lists are infuriating) 7-Remembered and/or fixed by user window position on screen 8-Rememberd last location on app by app basis This new filepicker might be a plugin until such time as it becomes commonplace as the default system filepicker.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420