The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 11

Status

()

Core
Widget: Win32
RESOLVED FIXED
5 years ago
5 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

5 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

5 years ago
Created attachment 582460 [details]
sample html

Comment 2

5 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

5 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

5 years ago
Interesting where this content gets stored:

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

Comment 5

5 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

5 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

5 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

5 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

5 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

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

Comment 11

5 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: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12

Updated

5 years ago
tracking-firefox11: ? → +

Comment 13

5 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

5 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.