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

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

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 24 Mar 2009 15:15:33 +0100
Message-ID: <op.urau77cm64w2qv@annevk-t60.oslo.opera.com>
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/
Received on Tuesday, 24 March 2009 07:15:33 GMT

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