When you get the value property of an <input type="file">, you're supposed to get C:\fakepath\<filename> instead of just <filename>.
Created attachment 39128 [details] work-in-progress
The code change looks pretty trivial. Any hints about how to write a test?
Created attachment 39130 [details] patch --- 5 files changed, 42 insertions(+), 14 deletions(-)
This is about the lamest thing ever. Why oh why would HTML5 spec this?
I would like to know what websites our current behavior breaks. Our behavior is much less-lame than HTML5's speced behavior/IE's behavior (assuming HTML5 is matching IE).
Comment on attachment 39130 [details] patch I guess I'll r- this based on my above comments. I think the spec should change instead of our implementation, unless there are a list of websites which break due to our (superior) behavior. :)
I agree with Eric, this is pretty lame. Does anyone know the rationale behind the decision?
I think it should be c:\awesomepath. /me ducks.
This is just too painfully idiotic a decision in the spec for words. Please, please, no. eseidel++ for the r-.
The rationale is as follows: 1) Some number of consumer routers won't let you upload new firmware with our current behavior because they try to trim off the non-existent path. Sadly, these sites can't fix the bug without new firmware. 2) IE8 ships with this behavior and ie-team shows little inclination to match our behavior because of (1). See http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx Maciej has stated on the HTML WG mailing list that he supports fakepath. There is some amount of debate on this topic in the HTML WG at present. It might make sense to wait and see how the dust settles, or it might sense to help resolve the situation.
Yes, this behavior is lame. But it seems to be the best available choice given the compatibility, platform-independence and privacy constraints. In particular: 1) Exposing the real path is a privacy/security risk. 2) Exposing Unix-style paths breaks some content, including router Web interfaces and apparently Orkut 3) Exposing bare filenames has some of the same issues as #1. Web developers still have the ability to get the real filename without regexp mangling by using control.fileList[0].fileName. More importantly, from a compatibility perspective, since other browsers are doing this, Web content authors *already* have to be prepared to strip the fakepath prefix. So we're not doing Web developers any favors by omitting it. And finally, while the lameness of this compatibility hack is very visible, it's hardly the lamest compatibility hack in the Web platform. Take a look at WebKit's "quirky em" unites or how parsing works when a <form> is misnested inside table structure. This hack just seems gross because it is easy to understand its wrongness without being an expert in the relevant part of the code.
The upshot of my comments is, I think we should just bite the pillow and get this change over with.
Comment on attachment 39130 [details] patch Here we are a year later and the spec hasn't changed. I think we should reconsider this path.
I foresee in the future we'll add a new property just to get the real name. This seems to run against Darin Adler's "The future is bigger than the past" argument in other bugs. I have a lot of faith in Hixie, but how many pages are we talking about? The sad thing is that it seems other browsers have done this too, which means we need to. We were just all stupid as a community to cave in the first place.
Believe me, I wouldn't have specced this if it wasn't a de facto standard backed with compatibility arguments. We already have an API for getting the name accurately: HTMLInputElement.files[0].name
Comment on attachment 39130 [details] patch > + if (!m_fileList->isEmpty()) { > + String value = "C:\\fakepath\\"; > + value.append(m_fileList->item(0)->fileName()); > + return value; > + } This can be written just with the plus operator: if (!m_fileList->isEmpty()) return C:\\fakepath\\" + m_fileList->item(0)->fileName(); I think that's more pleasant. But also, I think that the fakepath will be mysterious without a comment.
Created attachment 65867 [details] Patch for landing
Comment on attachment 65867 [details] Patch for landing Clearing flags on attachment: 65867 Committed r66343: <http://trac.webkit.org/changeset/66343>
All reviewed patches have been landed. Closing bug.
http://trac.webkit.org/changeset/66343 might have broken Qt Linux Release
-PASS fileInput.value is "DRTFakeFile" +FAIL fileInput.value should be DRTFakeFile. Was C:\fakepath\DRTFakeFile. These should be PASS, not FAIL.
> These should be PASS, not FAIL. Ok.
> These should be PASS, not FAIL. See Bug 44882.