Do not persist the "Save As" location in private browsing mode

VERIFIED FIXED in Firefox 3.1b2

Status

()

VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

({privacy, verified1.9.1})

Trunk
Firefox 3.1b2
privacy, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 +
in-testsuite +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

10 years ago
Created attachment 347138 [details] [diff] [review]
Patch (v1)

From bug 248970 comment 513:

Ehsan: are we persisting the "Save As..." location?  I completely forgot about
that being something that we need to clear.

This patch prevents the browser.download.lastDir pref from being saved inside the private browsing mode.
Attachment #347138 - Flags: review?(mconnor)
(Assignee)

Updated

10 years ago
Blocks: 248970
(Assignee)

Updated

10 years ago
Attachment #347138 - Flags: approval1.9.1b2?
(Assignee)

Comment 1

10 years ago
Comment on attachment 347138 [details] [diff] [review]
Patch (v1)

This would also be nice to take for Beta 2.
Comment on attachment 347138 [details] [diff] [review]
Patch (v1)

We set this pref in helper dialog code too:
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in#240

Seems like we should avoid that as well.
(Assignee)

Comment 3

10 years ago
Created attachment 347139 [details] [diff] [review]
Patch (v1.1)

(In reply to comment #2)
> (From update of attachment 347138 [details] [diff] [review])
> We set this pref in helper dialog code too:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in#240
> 
> Seems like we should avoid that as well.

That's right.  The new patch handles this as well.
Attachment #347138 - Attachment is obsolete: true
Attachment #347139 - Flags: review?(mconnor)
Attachment #347139 - Flags: approval1.9.1b2?
Attachment #347138 - Flags: review?(mconnor)
Attachment #347138 - Flags: approval1.9.1b2?
Attachment #347139 - Flags: review?(mconnor) → review+
Making this a blocker, approval won't be needed.
Flags: blocking-firefox3.1+
Target Milestone: --- → Firefox 3.1
(Assignee)

Updated

10 years ago
Flags: in-litmus?
(Assignee)

Comment 5

10 years ago
http://hg.mozilla.org/mozilla-central/rev/a0f72d018c4a
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Target Milestone: Firefox 3.1 → Firefox 3.1b2

Comment 6

10 years ago
So this change makes it not save the last saved directory instead of restoring it back to what it was before entering private browsing?

Seems like it would be annoying for those that download multiple files to the same directory in one private browsing session.
(Assignee)

Comment 7

10 years ago
(In reply to comment #6)
> So this change makes it not save the last saved directory instead of restoring
> it back to what it was before entering private browsing?
> 
> Seems like it would be annoying for those that download multiple files to the
> same directory in one private browsing session.

Hmmm, I agree.  Would you mind filing a follow-up bug and assigning it to me?  We can safely take that for the final release I suppose.

Updated

10 years ago
Blocks: 464795
Keywords: fixed1.9.1
(Assignee)

Comment 8

10 years ago
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Component: General → Private Browsing
(Assignee)

Updated

10 years ago
QA Contact: general → private.browsing
Ehsan: I am trying to write a test case for this and I am having trouble understanding what was changed even after reading Comment 6. Can you help clarify what was changed here?

Also, was a follow up bug ever filed per your request in Comment 7?
(In reply to comment #9)
> Ehsan: I am trying to write a test case for this and I am having trouble
> understanding what was changed even after reading Comment 6. Can you help
> clarify what was changed here?

In previous versions before this patch was checked-in the download directory from the PB session was used after leaving it. So probably the following steps are necessary for a testcase:

1. Set "Always ask me where to save files" inside the preference window
2. Open http://www.google.de
3. Save the Google logo to disk and choose a directory
4. Enter PB mode
5. Navigate to http://www.google.de and save the same logo to another location
6. Leave PB mode
7. Try to save the logo again

You should see the folder from step 3 instead of the one from step 5.

> Also, was a follow up bug ever filed per your request in Comment 7?

Yes, it is already on the blocking list. It's bug 464795.
Verified fixed with the steps given in comment 10 and the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081228 Shiretoko/3.1b3pre ID:20081228020322

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081228 Shiretoko/3.1b3pre ID:20081228032813
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
https://litmus.mozilla.org/show_test.cgi?id=7442 added to Litmus. Thanks to Henrik for scripting out the testcase, which I just made minor revisions to.
Flags: in-litmus? → in-litmus+
(In reply to comment #7)
> (In reply to comment #6)
> > So this change makes it not save the last saved directory instead of restoring
> > it back to what it was before entering private browsing?
> > 
> > Seems like it would be annoying for those that download multiple files to the
> > same directory in one private browsing session.
> 
> Hmmm, I agree.  Would you mind filing a follow-up bug and assigning it to me? 
> We can safely take that for the final release I suppose.

Ehsan, had we ever a bug on that? I can see this behavior on Linux now. No idea if this is a recent regression. Do you have a bug # handy?
Sorry, missed bug 464795.
(Assignee)

Comment 15

9 years ago
The tests for this bug were added in bug 464795.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.