W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 25 Mar 2009 21:39:42 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0903252100590.25082@hixie.dreamhostps.com>

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 14:39:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT