Open Bug 27493 Opened 25 years ago Updated 2 years ago

Default open/save directory isn't smart

Categories

(Firefox :: File Handling, defect, P3)

defect

Tracking

()

People

(Reporter: mpt, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: relnote-user no-eta)

The choice of default directory, which the file selector points at initially when opening or saving a file, could be a lot more intelligent. Build: 2000021014, Win98 To reproduce: * Create a folder in `My Documents' called `test'. Create an HTML file in the `test' folder called `blah.html'. * Start a fresh installation of Mozilla, and open a Navigator window. * Select File > Open File ... What should happen: * The file selector defaults to the `My Documents' directory (see below). What actually happens: * The file selector defaults to the `Seamonkey' directory (or whatever directory Mozilla was installed in). Continue ... * Use the file selector to open C:\My Documents\test\blah.html. * Select File > Open ... again. Observe that the file selector starts at the `test' directory, as it should. * Exit the file selector, and quit Mozilla. * Restart Mozilla, using the same profile, and select File > Open ... again. What should happen: * The file selector starts at the `test' directory, as before. What actually happens: * The file selector starts at a different directory (either `Seamonkey' or `My Documents', depending on whether the first problem above has been fixed). Continue ... * Use the file selector to open C:\My Documents\test\blah.html. * Rename the `test' directory to something else. * Select File > Open File ... again. What should happen: * Since the `test' directory no longer exists, the file selector reverts to its first option, the `My Documents' directory. What actually happens: * The file selector starts at the Desktop. How to fix these bugs: * Make the last-used directory persistent not only during a session, but between sessions. This can be done by storing it in prefs.js. * When an open/save dialog is about to be opened, open it in the following directory, in order of preference (if one doesn't exist, fall back to the next option): - Windows 1. Directory of current file (if local) 2. Last-used directory 3. {System drive}:\My Documents\ 4. Desktop - MacOS 1. Directory of current file (if local) 2. Last-used directory 3. {System drive}:Documents: 4. Desktop - Linux/Unix 1. Directory of current file (if local) 2. Last-used directory 3. ~/ 4. /
Keywords: pp
This is really a request for an enhancement. Changing severity to enhancement Changing Platforms and OS to All. Changing component to UE/UI.
Severity: normal → enhancement
Component: Browser-General → UE/UI
OS: Windows 98 → All
Hardware: PC → All
Moving UE/UI component bugs over to new User Interface: Design Feedback component. UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Agreed completely; changing component to XPApps for consideration. The only other thing I would consider would be keeping parallel recall for "Open" and "Save" for the directory of the current file and the last-used- directory, so that they could be independent - with the other used as fallback before continuing to 3 or 4 on the lists above. The last-used-directory as a fallback would fit in well with the enhancement suggested in bug 26480, "[RFE] Add MRU for folders/directories to File Save dialogs", M16. That enhancement would be complementary to this one. This is also related to bug 7840, "[RFE] Ability to designate default directory for FTP downloads", NEW, M15 -- doing what is suggested here would probably be considered a good fix for that bug. If it is intended to implement a full MRU list in the Save As dialogs, it would probably make sense to implement the backend save/recall for that before implementing what this bug is requesting.
Assignee: leger → don
Component: User Interface: Design Feedback → XPApps
QA Contact: cbegle → paulmac
QA Contact: paulmac → sairuh
Should multiple directories be saved (one for open, one for save; or one for images, another for webpages)?
Netscape 4.7x currently only remembers one directory for all open/save/etc. dialog boxes iirc. Having it remember separate directories would be great!
adding pavlov, who's working on the linux xul file picker. assigning to bill (who can reassign if this ain't his ball o'wax. :-)
Assignee: don → law
sidr, davidr8: Yes, separately persistent directories for opening and saving would make sense. However, I don't think having separately persistent directories for each media type (e.g. one for opening HTML, one for saving HTML, one for opening images, one for saving images, one for opening video ...) would be obvious enough to be useful. Indeed, many users would find it frustrating that months after they changed the name of their Work folder (for example), Mozilla was still for looking for the old directory when opening/saving rarely-used file types.
I agree for media types (IE5 does split them and it's annoying), and could go either way on open/save (I tend to type urls for local files, but hmm they're always in the same directory and not the same as where I save things).
*** Bug 38526 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
Depends on: 30453
*** Bug 34974 has been marked as a duplicate of this bug. ***
*** Bug 55478 has been marked as a duplicate of this bug. ***
*** Bug 56782 has been marked as a duplicate of this bug. ***
Semi-obvious implementation note: On Mac and Windows the names of the above-mentioned folders depend on the language version of the system. Querying the appropriate API instead of using hard-coded paths is preferrable.
Severity: enhancement → normal
Keywords: pp4xp, helpwanted, relnoteRTM
Whiteboard: relnote-user
cc'ing mscott [wrt mpt's comments in bug 62389]...
nav triage team: Would be nice to have but don't think we'll get to it for beta1, marking nsbeta1-
Keywords: nsbeta1-
nav triage team: Renominating for nsbeta1, we should really fix these "default" directory things. Consider it one of those "things that should just work" things.
Keywords: nsbeta1-nsbeta1
Target Milestone: Future → ---
Suggest to add Keywords: *nsCatFood* and *mostfreq* since this should really be fixed ;) Also suggest to add a prefs: <> Always store files to selected directory. < -path - > [BROWSE] <> Store files to last used directory.
as long as win32 file picker gives me the places bar (and iirc mozilla disables that -- bad mozilla) I don't care :). However, for XP file picker, bryner was rewriting it.
Assignee: law → bryner
This bug should be a dupe of bug 7840, because that bug already incorporates the idea of smart open/save directories - in addition to being able to define a default directory (see comment from Peter Lairo 2001-01-10) Summary of fixes needed: - add to preferences > download files to this directory <BROWSE> OR > download files to last used directoy Also, BOTH bugs should receive the keywords: *nsCatFood* and *mostfreq*.
I think this bug should go over to law... this isn't really a linux filepicker issue, the last-directory tracking is done in xp code. The fact that the windows filepicker is more convenient is no reason to ignore the problem there.
Assignee: bryner → law
timeless: what's the "places bar"? Is that a feature in newer versions of Windows?
http://www.elementkjournals.com/msw/0103/msw0131a.gif this is o2k's (which is inferrior to the one included in w2k, but you get the idea).
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla0.9.2
nav triage: inconsistent user experience. kind of annoying. hence nsCatFood+.
Keywords: nsCatFoodnsCatFood+
nav triage: severity is not high, but frequency and annoyance high. keeping on m0.9.2 list.
Vishy, I don't understand your comment. This isn't really a "bug" is it (so I'm not sure what you mean by "severity" or what the "inconsistency" is). I am not sure we can implement this feature in mozilla0.9.2.
Whiteboard: relnote-user → relnote-user no-eta
nav triage: moving this m0.9.3 at least. this would be nice to have but not an rtm stopper.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
nav triage team: Too much work to be done for mozilla0.9.3. Also, Bill Law is on sabbatical. Marking mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
*** Bug 2226 has been marked as a duplicate of this bug. ***
If Mozilla is to incorporate a filepicker to replace the OS default arrangement, whoever is in charge of such a project would do well to visit a PC on which OS/2 and XFile (shareware) <http://hobbes.NMSU.edu/pub/os2/util/system/xfile14.zip> are installed. I've used both for over five years. When working on a Linux or windoze system the the UI clumsiness due to lack of XFile makes me miserable. Several months ago, one or two builds of OS/2 Mozilla incorporated a filepicker that resembled that from Lotus Smartsuite and windoze. This filepicker was miserable and overrode XFile. I reported same (see bug 69972 comment on May 09) and subsequently the Mozilla vacpp OS/2 builds made XFile work again, albeit retaining the 69972 bug. A few concepts incorporated by XFile: picklists for: recently accessed files recently accessed directories favorite/frequent directories custom open/save dialog size and placement
mrmazda, none of that has anything to do with this bug whatsoever.
If Mozilla is is to add a smart filepicker UI as a result of this bug, then I don't see how an example of a good add-in filepicker UI would fail to be relevant.
No, nothing in the filepicker UI needs to change as a result of this bug. All that needs to change, as the summary says, is the default open/save directory.
spam: over to File Handling.
Component: XP Apps → File Handling
In MachV, we will be addressing the initial defaults: My Documents on Windows, and the system download folder on Mac, for the rest ->future, help certainly wanted.
Target Milestone: mozilla1.0 → Future
No need for anything to be done on OS/2 except allow the default OS UI for file open/save to do its job. XFile can be installed to improve the default OS UI, and I absolutely hate it when an app usurps XFile, as Lotus SS does. I would hope there is a utility similar to XFile with same impact in Linux, though I haven't found one yet.
How can 4xp and nsCatFood+ be marked Future? Mozilla is consistently offering some obscure directory: "...\Accessories\TrayIcons\" as the "default" download directory (where did that setting come from?). I am tired of having to navigate manually to where I actually want downloads to go, namely always to: "...\Communications\Downloads\"! "Future" - bahumbug. [end of rant] PS. Should fixing 4xp bugs be a *minimum* requirement for releasing Mozilla 1.0?
Currently, it always wants to save pages to My Documents, and always wants to open files from the Mozilla directory (in Windows 98). It never changes, even within the same session, unlike Netscape 4. This is really annoying when I'm dealing with multiple files in the same directory and have to keep navigating to it.
If there is any workaround for this (edit some *.js file), PLEASE post it here. Are BILL and SAIRUH even still with the program? They haven't posted in 6 months. Even worse, BILL's last comment #25 was: "This isn't really a "bug"" :( - How can he fix a bug if he doesn't even agree that it is a bug? Could this bug please be reassigned? Also, could smeone with authority please add KW: mozilla0.9.9, nsBeta1 Yesterday, I had to attach 7 files and was forced to navigate to their directory 7 times! and select each file one-by-laborious-one.
I would agree that this isn't technically a "bug", since there's no mandatory standard anywhere with regard to what directory a file dialog ought to start on, but simple common sense should hold that, at least within the same session, each file dialog (for load or save) should start at the directory which was last used, for the simple reason that users often need to load or save multiple items to/from the same place one after another, and it's frustrating to have to keep navigating to the right directory. One can then quibble and argue about details such as which file dialogs should have separate memories of "last used directory" -- should they all use a single memory item, or should there be one for all "load" dialogs and another for all "save" dialogs, or should they be broken down more finely (all HTML loads/saves, all graphic loads/saves, etc.)? Should the current status be remembered only for the current session or persistently for a longer time? What directory should be the default if no previous directory was used? All of this can be a matter of great disagreement from people with varying preferences in these regards (and should, hence, ideally be made into preference settings that are user-configurable, if this is feasible to implement), but I think there is near-unanimous agreement that when you do multiple file accesses of the same sort in a row, a well-behaved program ought to start you at the same directory you were in when you did the last one.
This must be a bug in the implementation of the windows (and mac? but all the comments I see relate to windows only, and I think Mac folks want things handled in a different way anyway) platform-specific file pickers. The XUL XP one used by Unix does remember the last directory, and it remembers a separate directory for Open and for Save, which seems ideal.
*** Bug 120931 has been marked as a duplicate of this bug. ***
See also bug 161102, "Downloading dialog shouldn't use same directory for saving files and choosing apps".
This bug makes mozilla almost unusable for me - it is faster to exit mozilla and start netscape than to navigate file hierachies each time. Concerning my desired behaviour: start in the current directory. I realize that others will have different desires, but starting in the current directory must be a settable option.
QA Contact: sairuh → petersen
The major part of this bug - remembering the last used directory is already implemented. > How to fix these bugs: > > * Make the last-used directory persistent not only during a session, but > between > sessions. This can be done by storing it in prefs.js. That is already implemented. Look for a pref "browser.download.dir" in about:config. > * When an open/save dialog is about to be opened, open it in the following > directory, in order of preference (if one doesn't exist, fall back to the next > option): > > - Windows > 1. Directory of current file (if local) > 2. Last-used directory > 3. {System drive}:\My Documents\ > 4. Desktop 1. Not the current behavior (and it sounds like a good idea - if you're working locally you'll probably want other files from the same place) 2. The current behavior 3. Not the current behavior (and I don't want this behavior - I keep stuff on my desktop) 4. Not the current behavior (this would be nice)
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.