27493 - Default open/save directory isn't smart

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Matthew T (active 1999-2002)]

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

[Sitsofe Wheeler]

This is really a request for an enhancement. Changing severity to enhancement 
Changing Platforms and OS to All. Changing component to UE/UI.

Comment 2

[leger]

Moving UE/UI component bugs over to new User Interface: Design Feedback 
component.  UE/UI component will be deleted.

Comment 3

[Sean Richardson]

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.

Comment 4

[Jesse Ruderman]

Should multiple directories be saved (one for open, one for save; or one for 
images, another for webpages)?

Comment 5

[handel]

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

[sairuh (rarely reading bugmail)]

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. :-)

Comment 7

[Matthew T (active 1999-2002)]

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

[Jesse Ruderman]

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).

Comment 9

[Jae Gangemi]

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

Comment 10

[Matthew T (active 1999-2002)]

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

Comment 11

[Matthew T (active 1999-2002)]

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

Comment 12

[Matthew T (active 1999-2002)]

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

Comment 13

[Henri Sivonen (:hsivonen) (on vacation)]

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.

Comment 14

[sairuh (rarely reading bugmail)]

cc'ing mscott [wrt mpt's comments in bug 62389]...

Comment 15

[Paul Chen]

nav triage team:

Would be nice to have but don't think we'll get to it for beta1, marking
nsbeta1-

Comment 16

[Paul Chen]

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

[Peter Lairo]

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

[timeless]

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.

Comment 19

[Peter Lairo]

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*.

Comment 20

[Brian Ryner (not reading)]

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.

Comment 21

[Jesse Ruderman]

timeless: what's the "places bar"?  Is that a feature in newer versions of 
Windows?

Comment 22

[timeless]

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).

Comment 23

[Viswanath Ramachandran]

nav triage: inconsistent user experience. kind of annoying. hence nsCatFood+. 

Comment 24

[Viswanath Ramachandran]

nav triage: severity is not high, but frequency and annoyance high. keeping on 
m0.9.2 list. 

Comment 25

[Bill Law]

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

[Viswanath Ramachandran]

nav triage: moving this m0.9.3 at least. this would be nice to have but not an 
rtm stopper. 

Comment 27

[Paul Chen]

nav triage team:

Too much work to be done for mozilla0.9.3. Also, Bill Law is on sabbatical. 
Marking mozilla1.0

Comment 28

[Jesse Ruderman]

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

Comment 29

[Felix Miata]

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

Comment 30

[Matthew T (active 1999-2002)]

mrmazda, none of that has anything to do with this bug whatsoever.

Comment 31

[Felix Miata]

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.

Comment 32

[Matthew T (active 1999-2002)]

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 33

[sairuh (rarely reading bugmail)]

spam: over to File Handling.

Comment 34

[Peter Trudelle]

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.

Comment 35

[Felix Miata]

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

[Peter Lairo]

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

[Dan Tobias]

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

[Peter Lairo]

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

[Dan Tobias]

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

[Akkana Peck]

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

[sairuh (rarely reading bugmail)]

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

Comment 42

[Jesse Ruderman]

See also bug 161102, "Downloading dialog shouldn't use same directory for saving
files and choosing apps".

Comment 43

[aeb]

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.

Comment 44

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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)

Comment 45

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 46

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 48

[Jonathan Wakely]

Comment 47 is spam, but it looks like I don't have privs to tag comments here. Same MO as Bug 102132 comment 100, different login.

Comment 49

[:Gijs (he/him)]

(In reply to Jonathan Wakely from comment #48)

Comment 47 is spam, but it looks like I don't have privs to tag comments here. Same MO as Bug 102132 comment 100, different login.

Yes, unfortunately there's a sustained spam thing going on at the moment. People are working on it and will probably batch-deal with it.