Closed Bug 115148 Opened 23 years ago Closed 23 years ago

win32: Mozilla does not remember the last directory used to save

Categories

(Core Graveyard :: File Handling, defect, P1)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: gilles+mozilla, Assigned: bugs)

References

Details

(Keywords: platform-parity, regression)

Attachments

(1 file, 2 obsolete files)

better patch
3.10 KB, patch
Details | Diff | Splinter Review
2001121303 win98 Save an image or file in a dir other than the one suggested in the dialog. Try to save another one. Expected result: the directory used is the one used in the first save operation. Actual: the directory used is either c:\my documents or mozilla's install dir. It happens between saves and between restarts. It is working correctly with build 2001121103.
could this be a regression due to ben's recent checkins? will check later on if this is also a problem on linux...
->ben, since bill will be away for the next several days.
Assignee: law → ben
With 2001121321 linux: last dir is remembered between saves in the same session and is not remembered between restarts.
OS: Windows 98 → All
this WFM on linux and mac os x, 2001.12.14.0x builds. if this is still a problem with a more recent build, do reopen --it could be limited to win32.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
It's not working on win98 2001121403.
Status: RESOLVED → REOPENED
OS: All → Windows 98
Resolution: WORKSFORME → ---
*** Bug 115543 has been marked as a duplicate of this bug. ***
This seems to be a problem on win95/win98 but not on win2k or WinME (that last is puzzling to me if 95/98 are broken).
*** Bug 115718 has been marked as a duplicate of this bug. ***
Summary: Mozilla does not save last directory used to save → Mozilla does not remember the last directory used to save
*** Bug 115824 has been marked as a duplicate of this bug. ***
*** Bug 115718 has been marked as a duplicate of this bug. ***
seems limited to win32.
Keywords: pp
Summary: Mozilla does not remember the last directory used to save → win32: Mozilla does not remember the last directory used to save
It may be limited to Windows 98. It sure is annoying for those of us stuck with Win 98, though. Can we upgrade the severity of this one to critical or blocker?
I just got e-mail from a fellow Bugzilla denizen. He confirms this bug on Windows 95.
At the least, can someone try and figure out which checkin is responsible? If it's not some critical code, maybe that checkin can be backed out until this if fixed? Please?
on w2k is it possible that the 'save page as' code and 'save image' code is using the same firing mechanism to save the directory information? The dialog box is exactly the same here using both methods. eg one affect remembering of the other.
*** Bug 116663 has been marked as a duplicate of this bug. ***
*** Bug 116698 has been marked as a duplicate of this bug. ***
Not quite MOSTFREQ, but getting there...
*** Bug 116831 has been marked as a duplicate of this bug. ***
*** Bug 116858 has been marked as a duplicate of this bug. ***
Not having the ability to pull code and build this myself, all I can contribute is that the 2001-12-11-09 ZIP build works. The next available Win32 build is 2001-12-12-06, and it doesn't work. So whatever broke this was obviously checked in during that time.
i think it has someting to do with the new feature to save whole pages including pictures.
*** Bug 117411 has been marked as a duplicate of this bug. ***
*** Bug 117408 has been marked as a duplicate of this bug. ***
*** Bug 117494 has been marked as a duplicate of this bug. ***
Warner, code changes and the save as web page complete: most likely changed this with the bug 11632. Which was checked into the trunk on 12-11.
*** Bug 117533 has been marked as a duplicate of this bug. ***
*** Bug 117896 has been marked as a duplicate of this bug. ***
This also affects NT 4.0 sp6, not just Win 95-Me.
*** Bug 118032 has been marked as a duplicate of this bug. ***
*** Bug 118189 has been marked as a duplicate of this bug. ***
Sorry, Ben and Sairuh. I don't want to be a PITA, but 16 dupes in about 20 days makes this a candidate for MOSTFREQ or something, wouldn't it?
the same version that loses paths isn´t able to store html-files in the network ... means - File - SAVE PAGE AS - network - server - share - directory doesn´t work after choosing the right folder and giving the right name .. you get a neverending context-menu and the file(s) did not download.
Separate bug, please.
Yes. While that may or not be related, in 0.9.7, which exhibits this bug, saving complete pages functions fine. It is indeed separate. You should open a new bug, and maybe mention this one in your description comment.
Status: REOPENED → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.8
Attached patch fix (obsolete) — — Splinter Review
fixes this bug by remembering the download dir & also the bug about persisting the last selected filter.
Could we make the "filterindexforcontenttype" be "filter_index_for_content_type" instead? Also, is the "/" from the content type valid in a pref name?
Attached patch patch that works (obsolete) — — Splinter Review
OK.. problem in widget (file picker wasn't setting the filter index of the native file picker before opening it) fixed here... also, restricting the memory of the selected filter to the instances when a converter is being selected, rather than a save type. As a result, changing the pref name
Attachment #63910 - Attachment is obsolete: true
What about the xhtml type? application/xml+xhtml or something like that?
er, make that application/xhtml+xml
Ben, That looks like it *uses* the pref for the default selection index only for text/html and text/xml (whatever flavors of the latter), but, it resets the pref for *all* types. Should resetting the pref be restricted to the same set of content-types?
Attached patch better patch — — Splinter Review
move the content type checking stuff used in a couple of places into a separate function, use the result of a single call to that in the foundHeaderInfo function to replace various checks. Also, only set the converter index pref if we've been saving a document (and thus had the document filter set)
Attachment #63939 - Attachment is obsolete: true
see my initial patch in bug #72623 I don't think you want to use get / set XFilePref. you want get / set complex value. bnesse or alecf would know for sure. note, I'll follow your lead of "browser.download.dir" and name my pref something similar, like "compose.attach.dir" or "mail.saveas.dir", etc.
fyi, I'm going with mail.compose.attach.dir and messenger.save.dir.
nsIPref is depricated. Please do not write new code that uses it. Use nsIPrefService and nsIPrefBranch instead. There are plenty of JS examples as I have purged nsIPref from all JS files except the Preferences panel.
*** Bug 119552 has been marked as a duplicate of this bug. ***
It seems like this bug is related to bug 27493, though this one is Windows-specific and the other is more general.
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Ben, should this be fixed on build 2002011503, then? It doesn't seem to work when I do a "Save Image" from the context menu; it's still defaulting to my Documents directory.
I'm not sure who marked this fixed, but it was a tad premature. 2002011503 does not reflect anythign being fixed, although this build may not contain it. Waiting till tomorrow's build to reopen. Ben, please do not make me take away your blankie again.
I re-landed it.
That's what Amelia Erheart said...
It's working correctly in build 2002011604. However, the file dialogs to *load* a file (for "Open File" and for the file selector in form inputs) still don't remember the last-used directory. Does this need to be opened up as a different bug (or is it already)?
Works great in 1604. ben: Go have yourself a cookie. ;)
Status: RESOLVED → VERIFIED
*** Bug 120561 has been marked as a duplicate of this bug. ***
*** Bug 120839 has been marked as a duplicate of this bug. ***
This bug has been verified fixed. I'm using 0.9.7, Build ID: 2002011803, on Windows 98, with a fresh profile, and I'm still getting this problem, however. Mozilla isn't remembering the last directory used to save a file, such as the www.mozilla.org front page. Is it just me?
Please ignore my last comment. It's working fine for me. I apologize for the spam.
*** Bug 120981 has been marked as a duplicate of this bug. ***
*** Bug 121268 has been marked as a duplicate of this bug. ***
*** Bug 122219 has been marked as a duplicate of this bug. ***
Dan, regarding comment #53, I believe that appears to be bug 120931.
*** Bug 123472 has been marked as a duplicate of this bug. ***
*** Bug 133744 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: