Re: [whatwg] C:\fakepath\ in HTML5
On Thu, 26 Mar 2009, Randy Drielinger wrote: With the risk of not being compliant with other OS's, but isn't using file://localpath/real_file_name.extension (so using file://localpath/ by default) the solution for the original suggestion? This ensures not breaking anything on existing websites and is a far more logical name for the whole workaround. While this might have been better, I think that since IE8 and Opera have both implemented and shipped this, a change would have to be really compelling to be adopted. I'm not sure this is really compelling. On Sun, 29 Mar 2009, Randy Drielinger wrote: My alternative (or any similar proposal) is way better than C:\fakepath, ensuring cross-platform uniform (expected) behavior. How is a fixed C:\fakepath\ prefix not cross-platform and uniform? With the risk of repeating myself, are we forcing the specs to cover all possible exceptions JS-programmers create? We're forcing the specs to cover whatever is needed for an implementation to support legacy content. On Sat, 11 Apr 2009, Nils Dagsson Moskopp wrote: Am Dienstag, den 24.03.2009, 08:18 + schrieb Ian Hickson: 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. Designating the router as element of the trusted zone (intranet) again (they reportedly took it out with IE8) should fix that, or shouldn't it? I'm not that familiar with MSFT software. In general I don't think we should be encouraging more use of IE's modes. They're a big enough mess as it is. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? What we apparently do not have here is cold, hard data. As you said on many other occasions, use cases need to be laid out clearly. Since this (IMHO extremely confusing) inconsistent change will be enshrined for generations to come, I am against it - unless the number of (public !) sites is so big that we can't fix that problem otherwise. I agree that better data would be great, but it's not clear how to find this data. File upload controls tend to be hidden behind password- protected pages and thus hard to discover. I followed their lead because I have found that speccing something that is already implemented is more effective than inventing new syntaxes when it comes to getting implementations. In this particular case, it also seems that the ./ syntax wouldn't in fact fix the bugs that were found. Fixing the buggy web pages would also fix stuff. Why can't this be part of IE compatibility mode? I'd rather not have to spec additional modes as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
Am Dienstag, den 24.03.2009, 08:18 + schrieb Ian Hickson: 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. Designating the router as element of the trusted zone (intranet) again (they reportedly took it out with IE8) should fix that, or shouldn't it ? I'm not that familiar with MSFT software. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? What we apparently do not have here is cold, hard data. As you said on many other occasions, use cases need to be laid out clearly. Since this (IMHO extremely confusing) inconsistent change will be enshrined for generations to come, I am against it - unless the number of (public !) sites is so big that we can't fix that problem otherwise. I followed their lead because I have found that speccing something that is already implemented is more effective than inventing new syntaxes when it comes to getting implementations. In this particular case, it also seems that the ./ syntax wouldn't in fact fix the bugs that were found. Fixing the buggy web pages would also fix stuff. Why can't this be part of IE compatibility mode ? -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] C:\fakepath\ in HTML5
Randy Drielinger ra...@prowebdesign.nl wrote: With the risk of not being compliant with other OS's, but isn't using file://localpath/real_file_name.extension (so using file://localpath/ by default) the solution for the original suggestion? This ensures not breaking anything on existing websites and is a far more logical name for the whole workaround. How does using a number of /'s and ZERO \'s increase the likelihood of compatibility with web apps which are clearly looking for \'s?
Re: [whatwg] C:\fakepath\ in HTML5
Referring to an example posted earlier:
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
this specific example would still work (regardless of the fact that this
type of code is so outdated, it could need some re-work ;-)
My alternative (or any similar proposal) is way better than C:\fakepath,
ensuring cross-platform uniform (expected) behavior.
With the risk of repeating myself, are we forcing the specs to cover all
possible exceptions JS-programmers create?
- Original Message -
From: timeless timel...@gmail.com
To: Randy Drielinger ra...@prowebdesign.nl
Cc: wha...@whatwg.org
Sent: Sunday, March 29, 2009 9:47 AM
Subject: Re: [whatwg] C:\fakepath\ in HTML5
Randy Drielinger ra...@prowebdesign.nl wrote:
With the risk of not being compliant with other OS's, but isn't using
file://localpath/real_file_name.extension (so using file://localpath/
by
default)
the solution for the original suggestion?
This ensures not breaking anything on existing websites and is a far more
logical name for the whole workaround.
How does using a number of /'s and ZERO \'s increase the likelihood
of compatibility with web apps which are clearly looking for \'s?
Re: [whatwg] C:\fakepath\ in HTML5
Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . With the risk of not being compliant with other OS's, but isn't using file://localpath/real_file_name.extension (so using file://localpath/ by default) the solution for the original suggestion? This ensures not breaking anything on existing websites and is a far more logical name for the whole workaround. my 2cents - Original Message - From: ddailey ddai...@zoominternet.net To: Ian Hickson i...@hixie.ch; wha...@whatwg.org Sent: Wednesday, March 25, 2009 11:26 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 While on the topic, something vaguely similar came to mind. If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which web site visitors can slide tiles around through a grid, we might wish to detect, through script, when the puzzle has been solved. This means interrogating the value of Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . Hence, script to determine if the puzzle has been solved has to resort to a wee bit of mischief to untangle the issue. Over the past nine years or so, I've seen at least a half dozen different strategies employed by various browsers to deal with the issue, ranging from the sensible to the bizarre, varying as a function of where the file is found (in local drive space, networked files, or even files served from the web). Where might we expect things to settle down ultimately? cheers David P.S. I gather from what you've written here, that indeed the spec will simplify access to local drive space through input type=file eventually, hence allowing client-side image manipulation for web applications? Will this solution propagate outward into SVG as well, where it will also be quite useful, or only if the SVG is inlined in HTML? - Original Message - From: Ian Hickson i...@hixie.ch To: wha...@whatwg.org Sent: Wednesday, March 25, 2009 5:39 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 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
Re: [whatwg] C:\fakepath\ in HTML5
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
While on the topic, something vaguely similar came to mind. If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which web site visitors can slide tiles around through a grid, we might wish to detect, through script, when the puzzle has been solved. This means interrogating the value of Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . Hence, script to determine if the puzzle has been solved has to resort to a wee bit of mischief to untangle the issue. Over the past nine years or so, I've seen at least a half dozen different strategies employed by various browsers to deal with the issue, ranging from the sensible to the bizarre, varying as a function of where the file is found (in local drive space, networked files, or even files served from the web). Where might we expect things to settle down ultimately? cheers David P.S. I gather from what you've written here, that indeed the spec will simplify access to local drive space through input type=file eventually, hence allowing client-side image manipulation for web applications? Will this solution propagate outward into SVG as well, where it will also be quite useful, or only if the SVG is inlined in HTML? - Original Message - From: Ian Hickson i...@hixie.ch To: wha...@whatwg.org Sent: Wednesday, March 25, 2009 5:39 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 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
Re: [whatwg] C:\fakepath\ in HTML5
On 24.03.2009, at 8:09, Ian Hickson wrote: (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) FWIW, WebKit returns just the file name now. - WBR, Alexey Proskuryakov
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, 23 Mar 2009, Alex Henrie wrote: On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote: I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4? No, but it _is_ intended to be compatible enough with existing content that user agents will be willing to implement it. On Tue, 24 Mar 2009, Boris Zbarsky wrote: I don't believe I've seen many bugs along these lines for Firefox... can't think of any, in fact. It seems that the number of such sites might be low enough that we don't need to cater to them. That's encouraging. 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. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? This was originally brought up in the W3C HTMLWG: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6529 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote: That's encouraging. 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. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? This was originally brought up in the W3C HTMLWG: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6529 Speaking of which, if the value really needs a path separator, why not simply use ./filename instead of filename? BR, Julian
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value for the presence of either a slash or backslash.
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Which sites? Any site that *requires* a Windows path clearly isn't interested in inter-operating with other browsers/platforms; heck, it means they've limited their testing to just Windows/IE. Don't punish the rest of us for their poor testing/programming. My friend ! Welcome to the internet :) opera adopted this behavior because for a long time we were the only ones with only the file name. And for a long time we always had compatibility problems, and sites that simply refused to fix. I recall Orkut avatar upload (checked for : in input.value), and some router firmwares. So, while keeping the privacy of the user we added c:\fake_path for the reasons mentioned. It's a sad true, but it was necessary. - Bil -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Lachlan Hunt wrote:
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
I just tried this in a current Firefox. The site worksforme, if we're
talking about the ZIP upload on the front page.
The code you mentioned is commented out in their JS, like so:
/* KRC 6/19/2008 #8234
...
*/
They still have various other silly checks (like requiring a filename
that's at least 6 characters long without telling the user that's what
they require), but that's not really relevant to this discussion.
-Boris
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@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/
Re: [whatwg] C:\fakepath\ in HTML5
So instead of fixing the web, we're fixing the spec (and thus implementing
fakepath in browsers)?
- Original Message -
From: Lachlan Hunt lachlan.h...@lachy.id.au
To: Ian Hickson i...@hixie.ch
Cc: wha...@whatwg.org
Sent: Tuesday, March 24, 2009 11:00 AM
Subject: Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value for the presence of either a slash or backslash.
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false; }
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Randy Drielinger wrote: So instead of fixing the web, we're fixing the spec (and thus implementing fakepath in browsers)? It's purely a question of what browser makers are prepared to implement. The spec has to reflect a consensus amongst browser makers so that it actualy gets implemented, otherwise it is no use to anyone. If you don't want the fakepath thing (and I agree it is ugly), try convincing the known-broken sites to change (citing the fact that they may break in Firefox could give you quite some leverage here). The fewer compat. reasons there are to keep the ugly solution, the easier it is to have the pretty solution.
Re: [whatwg] C:\fakepath\ in HTML5
Am Dienstag, den 24.03.2009, 16:06 +0100 schrieb James Graham: If you don't want the fakepath thing (and I agree it is ugly), try convincing the known-broken sites to change (citing the fact that they may break in Firefox could give you quite some leverage here). From what I remember, Opera were the ones that were good with statistics. Lan you provide a list on what major sites / routers / frameworks are broken or - if that is too much - how common this is ? Or should I ask MSFT ? IMHO, it would be a shame if this broken behaviour would be enshrined for centuries to come. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote on 3/24/2009 12:09 AM: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. 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. - Bil
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@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 HTTP. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie alexhenri...@gmail.com wrote: On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com wrote: 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. Maybe, maybe not. 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? I have no idea. It just indicates issues are out there. 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. I don't see how this example could work. Anyway, relying on .value to just return a filename is a bogus assumption anyway since lots of user agents out there are not doing that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] C:\fakepath\ in HTML5
Bil Corry wrote on 3/24/2009 11:01 AM: Ian Hickson wrote on 3/24/2009 12:09 AM: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. 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. And when sending the file to the server, IE8 sends just the filename without the fake path for the Internet zone, and send the real path and filename for the Trusted zone. - Bil
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 10:34 AM, Anne van Kesteren ann...@opera.com 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. I don't see how this example could work. Anyway, relying on .value to just return a filename is a bogus assumption anyway since lots of user agents out there are not doing that. I mean, if the browser used C:\fakepath\upload.txt in both JavaScript and DOM then there would be no problem in this example. But mixing C:\fakepath\upload.txt and upload.txt creates additional complications. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 11:24 AM, Alex Henrie alexhenri...@gmail.com wrote: I mean, if the browser used C:\fakepath\upload.txt in both JavaScript and DOM then there would be no problem in this example. But mixing C:\fakepath\upload.txt and upload.txt creates additional complications. Whoops, that should have said JavaScript and HTTP, sorry. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Mar 24, 2009, at 12:31 AM, Alexey Proskuryakov wrote: On 24.03.2009, at 8:09, Ian Hickson wrote: (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) FWIW, WebKit returns just the file name now. It should also be noted that we have not received any compatibility bugs since making this change.
[whatwg] C:\fakepath\ in HTML5
Dear WHATWG, Recently section 4.10.4.3 of the HTML5 specification was changed to recommend that C:\fakepath\ be prepended to the DOM value of file upload input elements. For example, when uploading /home/alex/upload.txt, JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8 and Opera 10; Firefox and Opera 9 return upload.txt and Safari and Chrome return /home/alex/upload.txt. I posted comments about this under the name Anonymous Coward on the IEBlog. As a web developer who will have to design around this, I would like to voice my strong objection to the change. First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. Second, this change is unintuitive. No novice is going to look at C:\fakepath\upload.txt and say Oh, that makes perfect sense. Developers on Linux, Mac OS, and BSD are really going to be raising their eyebrows—Unix systems don't even use backslashes in paths, they use forward slashes instead. The change makes even less sense when what is actually sent over HTTP is just upload.txt. The difference between the DOM and HTTP will make it more difficult to design advanced web applications. I thought the point of HTML5 was to resolve problems in HTML, not to drag along hacks and baggage implemented in some browsers but not others. But this, this is just ugly. Sincerely, Alex Henrie
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, 23 Mar 2009, Alex Henrie wrote: Recently section 4.10.4.3 of the HTML5 specification was changed to recommend that C:\fakepath\ be prepended to the DOM value of file upload input elements. For example, when uploading /home/alex/upload.txt, JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8 and Opera 10; Firefox and Opera 9 return upload.txt and Safari and Chrome return /home/alex/upload.txt. I'm surprised Chrome returns a Unix path; is this on Windows? First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) I thought the point of HTML5 was to resolve problems in HTML, not to drag along hacks and baggage implemented in some browsers but not others. But this, this is just ugly. I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote: I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4? -Alex
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). I don't believe I've seen many bugs along these lines for Firefox... can't think of any, in fact. It seems that the number of such sites might be low enough that we don't need to cater to them. Put another way, the costs of changing this in Gecko seem, to me, to outweigh the benefits. (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) It doesn't feel that this is an area where we need more compatibility at the moment, and I'm pretty strongly opposed to the spec enshrining this behavior. In fact, if the spec did not specify such a behavior it would be easier to convince sites to fix their code instead of making bogus assumptions about the return value... I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( While true, this doesn't seem like one of those cases, to me. -Boris
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 1:09 AM, Ian Hickson i...@hixie.ch wrote: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they Chance of this happening is only for intranet site. So if browser vendors want to support it, it should be a config option. Out of box setting should default only filename.ext
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote on 3/24/2009 12:09 AM: On Mon, 23 Mar 2009, Alex Henrie wrote: First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. Which sites? Any site that *requires* a Windows path clearly isn't interested in inter-operating with other browsers/platforms; heck, it means they've limited their testing to just Windows/IE. Don't punish the rest of us for their poor testing/programming. - Bil
