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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
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?
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=
Beltzner: this is a privacy leak, would we want to take it on 1.9.1.x?
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
(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).
Nominating to get on the radar.
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.
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.
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.
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.
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.
Created attachment 382014 [details] [diff] [review] Patch (v1) Patch + tests. This patch stores the last open directory in a new pref called browser.open.lastDir.
Attachment #382014 - Flags: review?(mconnor)
Is mconnor still the right reviewer here?
status1.9.1: --- → wanted
Whiteboard: [needs r=mconnor]
(In reply to comment #13) > Is mconnor still the right reviewer here? Yes.
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!
Attachment #382014 - Flags: review?(mconnor) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs r=mconnor]
Target Milestone: --- → Firefox 3.6a1
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
Status: RESOLVED → VERIFIED
Comment on attachment 382014 [details] [diff] [review] Patch (v1) Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #382014 - Flags: approval126.96.36.199? → approval188.8.131.52+
status1.9.1: wanted → .4-fixed
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:184.108.40.206pre) 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.
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?
I can confirm the result from comment #21 after the step 3 for a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11pre) 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.
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:18.104.22.168pre) 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.
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?
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?
You need to log in before you can comment on or make changes to this bug.