496123 - the last download directory from private browsing persists as the initial directory for the filepicker after stopping private browsing

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect)

Description

[Ilja Sekler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090602 Firefox/3.6a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090602 Firefox/3.6a1pre

Similar to Bug 483481, but about the filepicker remembering the wrong directory when opening local files after leaving the private browsing mode. The initial filepicker directory gets reset first if Firefox is restarted.

Can't test whether this problem exists only on GTK2.


Reproducible: Always

Steps to Reproduce:
1. Open <http://www.google.de> and save the Google logo to a folder A
2. Copy logo.gif from the folder A to folder B
3. Hit Ctrl+O, navigate to folder B, open logo.gif in Firefox
4. Start Private Browsing
5. Open <http://www.google.de> and save the Google logo to a folder C
6. Stop Private Browsing
7. Click on 'File' / 'Open File' (or hit Ctrl+O)
Actual Results:  
The filepicker shows the content of the folder C

Expected Results:  
The filepicker shows the folder B

Tested on Ubuntu 9.04.

Comment 1

[Marcia Knous [:marcia]]

Confirming - the same thing happens using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090603 Shiretoko/3.5pre.

Comment 2

[(no longer active)]

So, what happens if you omit steps 2 and 3?  Also, what folder would be chosen if you save the google logo in step 7 instead of trying to open a file?

What is the value of browser.download.lastDir at step 7?

Comment 3

[Marcia Knous [:marcia]]

Using the build noted in Comment 1, the same thing happens - The filepickers shows the contents of Folder C.

If I try to open the google.de page and save the file again, the filepicker shows Folder A.

browser.download.lastDir value is -> AAAAAAFeAAIAAQxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADD4uSKSCsAAAAKpK8IRm9sZGVyIEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFvg8ZL1jcAAAAAAAAAAP////8AAAkgAAAAAAAAAAAAAAAAAAAAB0Rlc2t0b3AAABAACAAAw+NVCgAAABEACAAAxkw4pwAAAAEADAAKpK8ACqSaAAB63AACACpNYWNpbnRvc2ggSEQ6VXNlcnM6bWFyY2lhOkRlc2t0b3A6Rm9sZGVyIEEADgASAAgARgBvAGwAZABlAHIAIABBAA8AGgAMAE0AYQBjAGkAbgB0AG8AcwBoACAASABEABIAHVVzZXJzL21hcmNpYS9EZXNrdG9wL0ZvbGRlciBBAAATAAEvAAAVAAIADf//AAA=

Comment 4

[(no longer active)]

Beltzner: this is a privacy leak, would we want to take it on 1.9.1.x?

Comment 5

[Ilja Sekler]

(In reply to comment #2)

Actually, everything stated in Comment #3 applies equally to the trunk using a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090603 Firefox/3.6a1pre, built from <http://hg.mozilla.org/mozilla-central/rev/80fc6fb7ee6d>.

> So, what happens if you omit steps 2 and 3?

The "Expected Results" would be folder A ;-)

Steps 2 and 3 are merely ornamental, to compare the filepicker behavior when opened in exactly the same way (Ctrl+O).

> What is the value of browser.download.lastDir at step 7?

The absolute path to the folder A (as it should be).

Comment 6

[Marcia Knous [:marcia]]

Nominating to get on the radar.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Trying to understand this. Opening files in Firefox with File > Open isn't a very common user action, and I wouldn't block the final release on it. However, if it's the case that when I SAVE a file to a directory "Foo" whilst Private Browsing that directory "Foo" is then shown when someone else tries to SAVE a file, this would block.

But I thought that was a different bug, which we fixed.

Basically, if this only happens with File > Open in PB mode *or* File > Open out of PB mode, not a blocker. If it happens with SAVE in PB mode *and* SAVE when out of PB mode, it is a blocker.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Aaron helped me with this on IRC:

20:32 < AaronMT> 1. Enter PB mode 2. File-> Open -> Open a picture from your pictures directory 3. Exit PB mode 4. File -> Open 5. Pictures folder is displayed
20:35 < beltzner> AaronMT: what if step 4 is File -> Save
20:37 < AaronMT> no leak
20:37 < AaronMT> right clicked a file, and saved image, and did save page as
20:38 < tchung> i tried the following:  1) open PB 2)go to page and File > Save As 3) Create a new folder someplace, and save page.  4) exit PB, and go to some url  5) File > Save as.  6) Folder is the last persisted folder in non-pb mode, not the folder you new folder you created in PB

Thanks guys, not blocking, we'll get it in 3.5.1.

Comment 9

[chris hofmann]

this is a slight variation on the test case that I tried using steps 4-6 in comment zero.

1. Start Private Browsing
2. Open <http://www.google.de> and save the Google logo to the desktop
3. Stop Private Browsing

view the download manager.  -- the google logo saved during PB mode is not shown in the list of downloads.

This seems to match what is spec'ed in 
https://wiki.mozilla.org/User:Mconnor/PrivateBrowsing#Downloads

  "Downloads will be removed from dlmgr on completion."

However that spec seems a bit unclear about what should happen to the actual file that was saved during PB.   I don't think it specifies that any file saved during PB mode will actually be removed from your hard drive upon existing PB mode.  That might be the behavior that some expect if PB mode is advertized to "remove all traces of your activity" when in PB mode, but it might also be something technically hard to achieve.

What I found is that the google-logo.gif that I saved during PB mode was still on my desktop and viewable in the file manager or "file open" in the browser.

Safari has the exact same behavior, and the warning message is also just as ambiguous about the file being removed from the download manager, but not actually being removed from your hard drive.

maybe both browsers should make it explicit in dialogs and documentation that files or folders created during private browser mode will get removed from the download manager listing, but not from your hard drive.

Comment 10

[(no longer active)]

Chris: if you use Firefox to download a file and open it directly inside an external application (i.e. it gets saved to the temp directory) while inside the private browsing mode, then we will delete it when you stop the private browisng mode (see bug 460609 where this was done).  This is exactly like what would happen with those files when you close Firefox even if you have never entered the private browsing mode.

But taking this to the next level of deleting any file downloaded inside the PB mode is getting carried away, because files which are explicitly downloaded by the user are never controlled by Firefox.  But I agree that this should be specified more clearly, so I'm adding the user-doc-needed keyword on bug 460609.

I think UI-wise we're doing enough, since we explicitly mention that in about:privatebrowsing which is displayed right after the user switches to the private browsing mode.

Comment 11

[(no longer active)]

The problem here is that we let the OS take control of the initial display directory, and don't set it ourselves, like we do for save file pickers.  We need to take control of it directly.

Comment 12

[(no longer active)]

Attachment: Patch (v1)

Patch + tests.  This patch stores the last open directory in a new pref called browser.open.lastDir.

Comment 13

[Samuel Sidler (old account; do not CC)]

Is mconnor still the right reviewer here?

Comment 14

[(no longer active)]

(In reply to comment #13)
> Is mconnor still the right reviewer here?

Yes.

Comment 15

[Mike Connor [:mconnor]]

Comment on attachment 382014 [details] [diff] [review]
Patch (v1)

So this has the effect of explicitly decoupling open and save lastDirs, which is actually just fine by me, since I don't think those overlap in significant ways.

r=me, thanks!

Comment 16

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/ccbffd1c5582

Comment 17

[Aaron Train [:aaronmt]]

Verified FIXED on trunk

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090802 Minefield/3.6a1pre

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 382014 [details] [diff] [review]
Patch (v1)

Approved for 1.9.1.4, a=dveditz for release-drivers

Comment 20

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ae3e5cfa0a43

Comment 21

[Al Billings [:abillings - ex-MoCo]]

This doesn't seem to be fixed in 1.9.1 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090917 Shiretoko/3.5.4pre.

Steps
1. Go to google.com
2. Save logo graphic to folder A
3. Do file - open

Result: folder A opens by default (correct)

4. Start private browsing mode
5. Go to google.com
6. Save logo graphic to folder B
7. Do file - open

Result: folder B opens by default (correct)

8. Stop private browsing
9. Do file - open

Result: folder B opens by default
Expected Result: folder A should open by default

Unless I'm misunderstanding things, this is still a privacy leak. The folder saved to inside of the private browsing session is the default folder from which to open files outside of the private browsing session instead of the original folder from before the session.

Comment 22

[(no longer active)]

What are folder A and folder B?  Can you please use custom folders that you've created yourself?  This patch should uncouple the last save and default open directories, so in fact what you see in step 3 should not happen.

Have you tried this on trunk builds, or on other platforms?

Comment 23

[Ilja Sekler]

I can confirm the result from comment #21 after the step 3 for a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090921 Shiretoko/3.5.4pre (SourceStamp=e0519724353b) with a clean new profile, but not after the step 7 (I get folder A) and not after 9 (still folder A). So, the privacy leak is fixed for me on 1.9.1.

Comment 24

[Al Billings [:abillings - ex-MoCo]]

I'm not trying trunk because I'm QA for the security releases (and those are all I care about normally). 

I made a folder called "a" and a folder called "b" on my desktop. Trying it with last night's build on my mac running OS X 10.6 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090921 Shiretoko/3.5.4pre), the result from comment #21 still occurs. After stopping private browsing mode, doing a file - open, opens folder "b" even though I first accessed it while in private browsing mode to save a file and have now exited file browsing mode. This was done with a brand new, clean, profile made for testing just now.

Comment 25

[Tim Riley [:timr]]

Can we get someone else to help out and verify this on trunk?  Whimboo or Tracy-  Do you guys have some time to help out?

Comment 26

[Tracy Walker [:tracy]]

following Al's step, I see folder B after exiting private browsing.  should be folder A.

seen on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090922 Minefield/3.7a1pre

regression since 20090829?