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

[Anne van Kesteren]

On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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.  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.

Microsoft did. And nothing changed in well over a year. (They say so in a  
comment on the blog post.)


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

Opera was the first doing this and we hit a few issues as well so we  
decided to go with a simple prefix (C:\fake_path\ changed to C:\fakepath\  
now per discussion with Microsoft). It looks a bit ugly, but it's not at  
all the issue that same make it out to be I think. (E.g. the initial email  
claimed this inconsistency between the DOM and HTTP would cause issues for  
Web application developers...) Furthermore, once we get interoperable  
support for <input type=file multiple> and the fileList proposal starts  
moving we can provide cleaner access directly to the file name there.


-- 
Anne van Kesteren
http://annevankesteren.nl/