Open
Bug 27493
Opened 25 years ago
Updated 2 years ago
Default open/save directory isn't smart
Categories
(Firefox :: File Handling, defect, P3)
Firefox
File Handling
Tracking
()
NEW
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. /
Comment 1•25 years ago
|
||
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
Comment 3•25 years ago
|
||
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
Updated•25 years ago
|
QA Contact: paulmac → sairuh
Comment 4•25 years ago
|
||
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!
Comment 6•25 years ago
|
||
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
Reporter | ||
Comment 7•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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).
Updated•25 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 10•24 years ago
|
||
*** Bug 34974 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 11•24 years ago
|
||
*** Bug 55478 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•24 years ago
|
||
*** 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.
Updated•24 years ago
|
Severity: enhancement → normal
Updated•24 years ago
|
Whiteboard: relnote-user
Comment 14•24 years ago
|
||
cc'ing mscott [wrt mpt's comments in bug 62389]...
Comment 15•24 years ago
|
||
nav triage team:
Would be nice to have but don't think we'll get to it for beta1, marking
nsbeta1-
Keywords: nsbeta1-
Comment 16•24 years ago
|
||
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.
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
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*.
Updated•24 years ago
|
Keywords: relnoteRTM → nsCatFood
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
timeless: what's the "places bar"? Is that a feature in newer versions of
Windows?
Comment 22•24 years ago
|
||
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).
Updated•24 years ago
|
Comment 23•24 years ago
|
||
nav triage: inconsistent user experience. kind of annoying. hence nsCatFood+.
Keywords: nsCatFood → nsCatFood+
Comment 24•23 years ago
|
||
nav triage: severity is not high, but frequency and annoyance high. keeping on
m0.9.2 list.
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
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
Comment 28•23 years ago
|
||
*** Bug 2226 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
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
Reporter | ||
Comment 30•23 years ago
|
||
mrmazda, none of that has anything to do with this bug whatsoever.
Comment 31•23 years ago
|
||
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.
Reporter | ||
Comment 32•23 years ago
|
||
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.
Comment 34•23 years ago
|
||
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
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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?
Comment 37•23 years ago
|
||
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.
Comment 38•23 years ago
|
||
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.
Comment 39•23 years ago
|
||
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.
Comment 40•23 years ago
|
||
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.
Comment 41•23 years ago
|
||
*** Bug 120931 has been marked as a duplicate of this bug. ***
Comment 42•22 years ago
|
||
See also bug 161102, "Downloading dialog shouldn't use same directory for saving
files and choosing apps".
Comment 43•22 years ago
|
||
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.
Updated•22 years ago
|
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)
Updated•16 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Updated•2 years ago
|
Severity: normal → S3
Comment 45•2 years ago
|
||
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)
Comment 46•2 years ago
|
||
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.
Description
•