file open box loses "location" after cancelling the open box

RESOLVED EXPIRED

Status

SeaMonkey
General
--
minor
RESOLVED EXPIRED
14 years ago
13 years ago

People

(Reporter: Mr. Moose, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210

When you do a file/open on a stored web page for the first time, you look at the
files in your home directory, ~foo,  Next, say I another file open into the
~foo/dir1 location and go about my business.  If I do a file/open again, the
file choices that come up are once again in ~foo/dir1 (and will continue to be
so until I open a file in another directory).  If I do a file/open and then
cancel the dialog box by either the "X" button in the upper right or the
"cancel" button and then do another file/open, I will no longer be looking in
~foo/dir1, but it will kick me back to my home directory and show me the files
back in ~foo.

This isn't a show stopper, but it is inconvenient to have to find the directory
I was looking in last

Reproducible: Always

Steps to Reproduce:
1.open a file in something other than your home directory
2.start to open a file with file/open, then click cancel
3.do a file/open and notice that the file choices automatically put you back in
your home directory

Actual Results:  
I am looking at files in the home directory

Expected Results:  
I expect to be looking at the files in the last directory in which a file was
opened.  mozilla usually keeps track of the last directory opened (and I would
expect it to do so), unless you hit the cancel/"X" button.
The right thing to do is to not set lastDirectory at
http://lxr.mozilla.org/seamonkey/source/xpfe/components/filepicker/src/nsFilePicker.js#223
if the retvals have a null dir (or maybe if the retvals show that the dialog was
cancelled).

Alternately, filepicker.js should set the directory in retvals even on cancel.

My personal preference is that we should store none of the state we are storing
there if the dialog was cancelled.
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.