Closed Bug 568373 Opened 14 years ago Closed 14 years ago

Private browsing saves the path of Uploaded files in Gmail

Categories

(Firefox :: Private Browsing, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox 3.7a5

People

(Reporter: daadaniel, Assigned: ehsan.akhgari)

References

()

Details

(Keywords: privacy)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

when using GMAIL in Private browsing mode Firefox saves the path used.

Reproducible: Always

Steps to Reproduce:
1.Start Private browsing
2.login into Gmail account and upload a file as attachment
3 [review].logout Gmail
4.Stop Private browsing
5.Login into Gmail account and upload a file

Actual Results:  
Firefox remembers the path of the attachment while in Private browsing when exiting private browsing 

Expected Results:  
Firefox should show the path for uploaded attachments used during normal operation (not using Private Browsing) and not remember what path was used to upload files while in Private Browsing.
Are you seeing this with the new Flash attachment uploader that gmail uses?  To test this, you can go to Tools > Add-ons, switch to the Plugins tab, disable the "Shockware Flash" plugin, refresh gmail, and try again.
Keywords: qawanted
Summary: Private browser saves the path of Uploaded files in Gmail → Private browsing saves the path of Uploaded files in Gmail
(In reply to comment #1)
> Are you seeing this with the new Flash attachment uploader that gmail uses?  To
> test this, you can go to Tools > Add-ons, switch to the Plugins tab, disable
> the "Shockware Flash" plugin, refresh gmail, and try again.

I have disabled Shockwave Flash and the problem is still there. Loging in to GMAIL in normal mode and choosing "Load Basic HTML" at the beginning of GMAIL login have the same result also.
Can you try running Firefox in safe mode?  <https://support.mozilla.com/en-US/kb/Safe+Mode>

Also, can you try this same problem with a nightly to see if you can reproduce it?  <http://nightly.mozilla.org/>
(In reply to comment #3)
> Can you try running Firefox in safe mode? 
> <https://support.mozilla.com/en-US/kb/Safe+Mode>
> 
> Also, can you try this same problem with a nightly to see if you can reproduce
> it?  <http://nightly.mozilla.org/>

I still get the same result after trying both of your suggestions. Safe Mode still keeps the path of uploaded file. I have tried Safe Mode in FF 3.6.3 and FF nightly. any other ideas?
Can't reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100504 Namoroka/3.6.5pre (.NET CLR 3.5.30729) ID:20100504042504

Daniel, how do the settings of the download manager look like? Please check those in the general pane of the preferences dialog.
Attached patch Patch (v1)Splinter Review
Figured the problem out.  When the content prefs backend is empty, we set the display directory to null, which causes the OS to use the last display directory shown inside the file picker.

As we can't control the OS-level cache of display directory, we should explicitly fall back to another directory if we can't find any.  The home directory seems to be a good choice for that.
Assignee: nobody → ehsan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #448301 - Flags: review?(roc)
Unfortunately, this is not possible to test automatically, since the problem relies on the actual OS-level dialog to appear, but we can't dismiss that dialog from inside js code, so we should just rely on a Litmus test here.
Flags: in-litmus?
Keywords: qawantedprivacy
Version: unspecified → Trunk
http://hg.mozilla.org/mozilla-central/rev/304ec3eb9cfd
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a5
Test bustage fix landed as http://hg.mozilla.org/mozilla-central/rev/cf7207710582.
Attached patch Windows bustage fix (obsolete) — Splinter Review
Apparently we don't have a useful "Home" on Windows, so we should fall back to Desktop on that platform.
Comment on attachment 448318 [details] [diff] [review]
Windows bustage fix

(I had to land this patch to make the tree green, but I'll incorporate any review comments in an after the fact landing).
Attachment #448318 - Flags: review?(roc)
Roc suggested to use the Desktop directory on all platforms.  For platforms which do not have a Desktop directory, it will fall back to Home.
Attachment #448318 - Attachment is obsolete: true
Attachment #448320 - Flags: review?(roc)
Attachment #448318 - Flags: review?(roc)
Why do we use the desktop and not the download folder on Windows and OS X? Also, about which content prefs do we talk? Can you please give some steps for a Litmus test?
(In reply to comment #15)
> Why do we use the desktop and not the download folder on Windows and OS X?

Because it would serve as the original file picker directory for uploading files, not downloading them.  :-)

> Also, about which content prefs do we talk? Can you please give some steps for
> a Litmus test?

By content prefs, I meant prefs stored inside the contentprefs modules.  Here is a set of STRs that you can use:

1. Use Tools > Clear Recent History to delete the recent history, making sure that the contentprefs are also deleted.
2. Start private browsing mode.
3. Go to a website (like Bugzilla's add an attachment page) with a file upload control.
4. Try to upload a file.  Verify that the initial directory of the file picker is Desktop.
5. Pick a file in a different directory.
6. Stop private browsing mode.
7. Go to the same website, and try to upload a file.  Verify that the file picker starts with your Desktop directory again.
Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12900
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: