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