Closed
Bug 229373
Opened 21 years ago
Closed 19 years ago
file open box loses "location" after cancelling the open box
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: halge, Unassigned)
Details
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.
Comment 1•21 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 2•19 years ago
|
||
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/
Comment 3•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•