Cannot upload images from URL to OS file upload dialogue since build 20111215

RESOLVED FIXED in Firefox 11

Status

()

Core
Widget: Win32
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: A, T, Assigned: jimm)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla12
x86
Windows 7
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(firefox11+ verified)

Details

(Whiteboard: [qa+] [testday-20120203] [qa!:11])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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

6 years ago
Created attachment 582460 [details]
sample html

Comment 2

6 years ago
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
Blocks: 661991
Status: UNCONFIRMED → NEW
Component: File Handling → Widget: Win32
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: file.handling → win32
Hardware: x86_64 → x86
(Assignee)

Comment 3

6 years ago
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".
(Assignee)

Comment 4

6 years ago
Interesting where this content gets stored:

C:\Users\jim\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\2TZ10TXB
(Assignee)

Comment 5

6 years ago
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.
tracking-firefox11: --- → ?
(Assignee)

Comment 6

6 years ago
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.
(Assignee)

Comment 7

6 years ago
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.
(Assignee)

Comment 8

6 years ago
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.
Assignee: nobody → jmathies
Attachment #582675 - Flags: review?(netzen)
(Assignee)

Updated

6 years ago
Blocks: 712335
Comment on attachment 582675 [details] [diff] [review]
fix

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

Looks good, also thanks for checking network shares.
Attachment #582675 - Flags: review?(netzen) → review+
Flags: in-litmus?
(Assignee)

Comment 10

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3dff9865d49d
(Assignee)

Comment 11

6 years ago
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.
Attachment #582675 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/3dff9865d49d
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12

Updated

6 years ago
tracking-firefox11: ? → +

Comment 13

6 years ago
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
Attachment #582675 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 14

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/4d6063f8ccd0
status-firefox11: --- → fixed
Whiteboard: [qa+]
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.
status-firefox11: fixed → verified
Whiteboard: [qa+] → [qa+] [testday-20120203] [qa!:11]
You need to log in before you can comment on or make changes to this bug.