Closed Bug 490273 Opened 11 years ago Closed 11 years ago

After saving a zip file, save as dialog treats zip file as directory to save next file

Categories

(Firefox :: Private Browsing, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: Noah, Assigned: ehsan)

References

Details

(Keywords: fixed1.9.1, Whiteboard: [fixed by latest patch in bug 464795])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Firefox/3.0

I found the regression range:
3-11 - works
3-12 - broken

This is obviously due to: Bug 464795 - Persist "save as" directory during private browsing, but restore previous value after

Save a zip from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/, then wait for the download to complete, find a image file (type of file may matter eg. exe, html, avi, wmv, etc), right-click > Save Image As, see that Save As dialog is inside zip archive and attempting to save image in this archive. I never went all the way thru and saw if the image actually saved there.

I assume any archive will do, not sure if it's limited to just zip. Someone else should try jar, 7zip, rar and so on. Also I've only been trying to save images afterward, so I'm not sure if the file type matters but it may.

My setup has the permanent private browsing pref turned on. But this should also happen when switching on & off PB when starting with this pref off.


Reproducible: Always
Ehsan: are we missing a .parent somewhere? I imagine this could happen if we specify the file itself as the displayDirectory...
(In reply to comment #1)
> Ehsan: are we missing a .parent somewhere? I imagine this could happen if we
> specify the file itself as the displayDirectory...

Yes, exactly.  Patch forthcoming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Attached patch Patch (v1)Splinter Review
This patch applies on top of the test patch in bug 464795 which is also awaiting your review.  :-)
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attachment #377649 - Flags: review?(gavin.sharp)
Blocks: 464795
Attachment #377649 - Flags: review?(gavin.sharp) → review?(johnath)
Attachment #377649 - Flags: review?(johnath) → review-
Comment on attachment 377649 [details] [diff] [review]
Patch (v1)

I talked to Ehsan about this, I wasn't sure why this special behavior was needed for the private browsing path, but not for the normal pref-path. He suspected it was related to the issue he discovered in bug 464795 comment 31, and I've confirmed that hypothesis by testing with the latest patch in that bug - it fixes this issue, so no need to take this patch.
Whiteboard: [fixed by latest patch in bug 464795]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Keywords: fixed1.9.1
Whiteboard: [fixed by latest patch in bug 464795]
Whiteboard: [fixed by latest patch in bug 464795]
You need to log in before you can comment on or make changes to this bug.