Since the 20111215 build, I cannot upload images directly from URL's anymore, and have to save the image to the drive normally before I can upload, I just get a blank now after trying to do it in any file upload screen. I normally use this on imageboards so it's fairly a big issue to me since it saved me a few steps since I discard images I upload a lot. Steps to reproduce: Find any random image, right click> copy image location/copy link location open any board on 4chan : http://boards.4chan.org/g/ press the 'browse' button in the post area under 'File' paste the URL into the file upload, click open. It should take a few seconds for it to save to the temp folder, you won't be able to do anything during this. Done. Expected result: The file area should be filled with a string of characters showing the location of the file. http://i.imgur.com/oVEjW.png Actual result: The file area is empty. http://i.imgur.com/AtkKW.png Tried with a new profile, it persists. Fx8 works fine, as does 20111214 and older builds. Currently using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111216 Firefox/11.0a1
Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/d508455660d3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111214 Firefox/11.0a1 ID:20111214125611 Fails: http://hg.mozilla.org/mozilla-central/rev/5131c0b1982f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111214 Firefox/11.0a1 ID:20111214132414 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d508455660d3&tochange=5131c0b1982f Triggered by: Bug 661991
Shouldn't too hard to track down. I didn't realize this was possible. I wonder if these temp files get deleted by the os after the operation completes, I'm guessing probably not. Which means we probably have a long standing privacy leak via this windows file picker "feature".
Interesting where this content gets stored: C:\Users\jim\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\2TZ10TXB
So far I haven't found a fix for this. We do get an IShellItem as a result, but querying it for a local path doesn't appear to be possible. The older XP calls work differently.
I think I found a fix - adding the FOS_FORCEFILESYSTEM option seems to address this. According to msdn, this "Ensures that returned items are file system items (SFGAO_FILESYSTEM)" which is what we ask for when we query the result.
Also, I've confirmed these files stick around in IE's cache, so we do have a long standing privacy leak here. Might be tough to address this though. I'll file a follow up.
Created attachment 582675 [details] [diff] [review] fix Note, I tested network shares to be sure this doesn't interfere with those types of paths. Everything seems to be working as expected.
Comment on attachment 582675 [details] [diff] [review] fix Review of attachment 582675 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, also thanks for checking network shares.
Comment on attachment 582675 [details] [diff] [review] fix This is a smallish bug fix for new Windows file picker functionality that's in aurora. This needs to go out with the original patches since it fixes a feature some users rely on.
Comment on attachment 582675 [details] [diff] [review] fix [triage comment] Approved for aurora. Regression fix for a regression introduced in Fx11/current Aurora. Risk looks small. Also marking this as tracking for Firefox 11
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 Verified in Firefox 11 Beta 1, on Windows 7, using sample html from comment 1. The path is copied in the text box.