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

Alex Henrie alexhenrie24 at gmail.com
Tue Mar 24 09:23:20 PDT 2009

On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren <annevk at opera.com> wrote:
> 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.)

Perhaps the buggy code was only sent to IE, and Firefox got more
reasonable code. If the firmware had working code for both Firefox and
the latest stable version of IE, that would explain the company's
reluctance to see a problem.

Another reason might be that this firmware only runs on old routers
and no firmware updates are being released for it, so few users would
run into the problem with trying to update firmware. What firmware was
this, exactly?

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

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


More information about the whatwg mailing list