[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@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.   `._.-(,_..'--(,_..'`-.;.'
>
>

Received on Wednesday, 25 March 2009 15:26:50 UTC