[whatwg] "C:\fakepath\" in HTML5

[Randy Drielinger]

> Image.src as resolved by the browser. In IE, Chrome and FF I noted today 
> (something different than it was a year or so ago) that for content served 
> from the local drive space (in Windows anyhow), document.images[x].src 
> resolves to file:///C:/ [path].  In Opera, it still resolves to 
> "file://localpath:/" .

With the risk of not being compliant with other OS's, but isn't using 
file://localpath/<real_file_name.extension> (so using file://localpath/ by 
default)
the solution for the original suggestion?

This ensures not breaking anything on existing websites and is a far more 
logical name for the whole workaround.

my 2cents




----- Original Message ----- 
From: "ddailey" <ddailey at zoominternet.net>
To: "Ian Hickson" <ian at hixie.ch>; <whatwg at whatwg.org>
Sent: Wednesday, March 25, 2009 11:26 PM
Subject: Re: [whatwg] "C:\fakepath\" in HTML5


> While on the topic, something vaguely similar came to mind.
>
> If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which 
> web site visitors can slide tiles around through a grid, we might wish to 
> detect, through script, when the puzzle has been "solved." This means 
> interrogating the value of
> Image.src as resolved by the browser. In IE, Chrome and FF I noted today 
> (something different than it was a year or so ago) that for content served 
> from the local drive space (in Windows anyhow), document.images[x].src 
> resolves to file:///C:/ [path].  In Opera, it still resolves to 
> "file://localpath:/" . Hence, script to determine if the puzzle has been 
> solved has to resort to a wee bit of mischief to untangle the issue. Over 
> the past nine years or so, I've seen at least a half dozen different 
> strategies employed by various browsers to deal with the issue, ranging 
> from the sensible to the bizarre, varying as a function of where the file 
> is found (in local drive space, networked files, or even files served from 
> the web). Where might we expect things to settle down ultimately?
>
> cheers
> David
>
> P.S. I gather from what you've written here, that indeed the spec will 
> simplify access to local drive space through input type=file eventually, 
> hence allowing client-side image manipulation for web applications? Will 
> this solution propagate outward into SVG as well, where it will also be 
> quite useful, or only if the SVG is inlined in HTML?
>
> ----- Original Message ----- 
> From: "Ian Hickson" <ian at hixie.ch>
> To: <whatwg at whatwg.org>
> Sent: Wednesday, March 25, 2009 5:39 PM
> Subject: Re: [whatwg] "C:\fakepath\" in HTML5
>
>
>>
>> The long and short of it with the c:\fakepath\ issue is that some browser
>> vendors have reported compatibility problems with not having this. I
>> acknowledge that there is some skepticism about whether this is a serious
>> enough issue to warrant this ugly hack, but given that the concerns were
>> raised by two browser vendors independently, it seems likely that we
>> should heed their advice.
>>
>> I don't think is a huge issue because we will in due course (when Arun's
>> spec is ready) be adding an API to <input type=file> that exposes the
>> actual files, filenames, types, etc, and the .value API will be 
>> vestigial.
>> (The .value API has other issues, like only exposing the first file in a
>> multiple-file upload widget.)
>>
>>
>> On Tue, 24 Mar 2009, Boris Zbarsky wrote:
>>> Ian Hickson wrote:
>>> > According to Microsoft:
>>> >
>>> >
>>> > http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
>>> >
>>> > ...the problem was with "a significant number of sites (e.g. education
>>> > products, several movie sharing sites, etc) and devices (e.g. popular
>>> > home routers)". The blog post above includes a screenshot of a
>>> > firmware upgrade screen that has this problem. This is not a site that
>>> > could be fixed.
>>>
>>> Sure it is.  You just need a browser that'll allow you to do a firmware
>>> upgrade to fix it.  Which means that if one gets such an upgrade shipped
>>> before all browsers stop sending paths, things seem to be ok.
>>
>> Realistically speaking, that seems unlikely to be practical. I wouldn't 
>> be
>> really surprised that someone would want to upgrade the firmware on a
>> device ten years from now, for instance. We never know.
>>
>>
>>> I agree they're not as happy as they could be, but they're ok.  In
>>> addition, is the expected lifetime of the affected device comparable to
>>> the expected time it takes to deploy the new behavior in browsers?  If
>>> so, it's worth it to contact the device maker and ask them to fix things
>>> in their next model instead of working around them.
>>
>> We both know that evanglisation efforts don't have a great success rate.
>>
>>
>>> As far as the "significant number of sites" above... I wonder whether
>>> there's UA sniffing going on here that causes some of these to assume
>>> certain things about IE only.  We've certainly seen quite a number of
>>> issues along those lines: we fix a bug, and discover that sites had
>>> written special browser-specific code taking advantage of that bug.
>>
>> Indeed, I wouldn't be surprised if this was why Opera and IE have seen
>> this problem, but Mozilla has not.
>>
>>
>> On Tue, 24 Mar 2009, Alex Henrie wrote:
>>>
>>> Example: A site lets a user upload a file and write some comments
>>> associated with that file. On the browser side, a new input element is
>>> dynamically created with the name and id "Notes for
>>> C:\fakepath\upload.txt". On the server side, the server receives
>>> "upload.txt" and looks for "Notes for upload.txt" to match. It of course
>>> is not there because the programmer had no idea that the browser would
>>> be adding appending a fake path in JavaScript but not in HTTP.
>>
>> That seems like a rather brittle design; what if the user uploads two
>> files with the same name, for instance? Or uploads an anonymous file 
>> (e.g.
>> a file obtained from an on-board camera)? Or changes the selected file? I
>> recommend using a unique ID instead, it's much more resilient. :-)
>>
>>
>> On Tue, 24 Mar 2009, Bil Corry wrote:
>>>
>>> I played with this a bit more, it turns out that IE8 returns
>>> "C:\fakepath\filename.ext" for sites in the Internet zone, but returns
>>> the real path for sites in the Trusted zone.  So even if HTML5 requires
>>> returning just the file name and is implemented as such in IE, the user
>>> can still designate their router as a Trusted Zone and be able to update
>>> their firmware.
>>
>> This is because the Trusted zone gets their less-standards-compliant 
>> "IE7"
>> mode. I don't think relying on this (or expecting other browsers to do
>> this) is a scalable strategy.
>>
>>
>> Here are some bugs that might be related to this issue:
>>
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=304939
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=473047
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=440991
>>
>> I haven't checked if they really are this problem, but it's possible.
>>
>> -- 
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>>
>
>