Last Comment Bug 711654 - Cannot upload images from URL to OS file upload dialogue since build 20111215
: Cannot upload images from URL to OS file upload dialogue since build 20111215
Status: RESOLVED FIXED
[qa+] [testday-20120203] [qa!:11]
: regression
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: mozilla12
Assigned To: Jim Mathies [:jimm]
:
Mentors:
Depends on:
Blocks: 712335 661991
  Show dependency treegraph
 
Reported: 2011-12-16 16:02 PST by A, T
Modified: 2012-02-03 08:42 PST (History)
11 users (show)
khuey: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified


Attachments
sample html (301 bytes, text/html)
2011-12-16 18:35 PST, Alice0775 White
no flags Details
fix (756 bytes, patch)
2011-12-18 08:32 PST, Jim Mathies [:jimm]
netzen: review+
christian: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description A, T 2011-12-16 16:02:34 PST
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
Comment 1 Alice0775 White 2011-12-16 18:35:14 PST
Created attachment 582460 [details]
sample html
Comment 2 Alice0775 White 2011-12-16 18:37:47 PST
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
Comment 3 Jim Mathies [:jimm] 2011-12-17 09:20:52 PST
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".
Comment 4 Jim Mathies [:jimm] 2011-12-17 11:13:44 PST
Interesting where this content gets stored:

C:\Users\jim\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\2TZ10TXB
Comment 5 Jim Mathies [:jimm] 2011-12-17 16:21:22 PST
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.
Comment 6 Jim Mathies [:jimm] 2011-12-18 08:13:17 PST
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.
Comment 7 Jim Mathies [:jimm] 2011-12-18 08:16:06 PST
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.
Comment 8 Jim Mathies [:jimm] 2011-12-18 08:32:39 PST
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 9 Brian R. Bondy [:bbondy] 2011-12-20 17:27:58 PST
Comment on attachment 582675 [details] [diff] [review]
fix

Review of attachment 582675 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, also thanks for checking network shares.
Comment 11 Jim Mathies [:jimm] 2011-12-21 08:32:57 PST
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 12 Ed Morley [:emorley] 2011-12-21 12:53:18 PST
https://hg.mozilla.org/mozilla-central/rev/3dff9865d49d
Comment 13 christian 2011-12-21 15:59:00 PST
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
Comment 15 Virgil Dicu [:virgil] [QA] 2012-02-03 08:42:19 PST
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.

Note You need to log in before you can comment on or make changes to this bug.