Bug 29000 - Implement HTML5's fakepath
Summary: Implement HTML5's fakepath
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2009-09-06 17:02 PDT by Adam Barth
Modified: 2010-08-30 12:15 PDT (History)
11 users (show)

See Also:

work-in-progress (924 bytes, patch)
2009-09-06 17:12 PDT, Adam Barth
no flags Details | Formatted Diff | Diff
patch (6.20 KB, patch)
2009-09-06 21:09 PDT, Adam Barth
no flags Details | Formatted Diff | Diff
Patch for landing (6.45 KB, patch)
2010-08-29 17:56 PDT, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2009-09-06 17:02:29 PDT
When you get the value property of an <input type="file">, you're supposed to get C:\fakepath\<filename> instead of just <filename>.
Comment 1 Adam Barth 2009-09-06 17:12:56 PDT
Created attachment 39128 [details]
Comment 2 Adam Barth 2009-09-06 17:14:21 PDT
The code change looks pretty trivial.  Any hints about how to write a test?
Comment 3 Adam Barth 2009-09-06 21:09:01 PDT
Created attachment 39130 [details]

 5 files changed, 42 insertions(+), 14 deletions(-)
Comment 4 Eric Seidel (no email) 2009-09-08 09:37:13 PDT
This is about the lamest thing ever.  Why oh why would HTML5 spec this?
Comment 5 Eric Seidel (no email) 2009-09-08 09:38:17 PDT
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 6 Eric Seidel (no email) 2009-09-08 14:46:33 PDT
Comment on attachment 39130 [details]

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. :)
Comment 7 Sam Weinig 2009-09-08 15:05:13 PDT
I agree with Eric, this is pretty lame. Does anyone know the rationale behind the decision?
Comment 8 Dimitri Glazkov (Google) 2009-09-08 15:08:58 PDT
I think it should be c:\awesomepath. /me ducks.
Comment 9 Gavin Barraclough 2009-09-08 15:21:35 PDT
This is just too painfully idiotic a decision in the spec for words.
Please, please, no.

eseidel++ for the r-.
Comment 10 Adam Barth 2009-09-08 18:27:35 PDT
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.
Comment 11 Maciej Stachowiak 2009-09-13 14:46:15 PDT
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.
Comment 12 Maciej Stachowiak 2009-09-13 14:47:55 PDT
The upshot of my comments is, I think we should just bite the pillow and get this change over with.
Comment 13 Adam Barth 2010-08-14 23:27:08 PDT
Comment on attachment 39130 [details]

Here we are a year later and the spec hasn't changed.  I think we should reconsider this path.
Comment 14 Eric Seidel (no email) 2010-08-15 07:52:41 PDT
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.
Comment 15 Ian 'Hixie' Hickson 2010-08-15 09:16:03 PDT
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 16 Darin Adler 2010-08-29 11:39:05 PDT
Comment on attachment 39130 [details]

> +        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.
Comment 17 Adam Barth 2010-08-29 17:56:45 PDT
Created attachment 65867 [details]
Patch for landing
Comment 18 WebKit Commit Bot 2010-08-29 18:16:42 PDT
Comment on attachment 65867 [details]
Patch for landing

Clearing flags on attachment: 65867

Committed r66343: <http://trac.webkit.org/changeset/66343>
Comment 19 WebKit Commit Bot 2010-08-29 18:16:48 PDT
All reviewed patches have been landed.  Closing bug.
Comment 20 WebKit Review Bot 2010-08-29 18:45:58 PDT
http://trac.webkit.org/changeset/66343 might have broken Qt Linux Release
Comment 21 Alexey Proskuryakov 2010-08-30 09:50:24 PDT
-PASS fileInput.value is "DRTFakeFile"
+FAIL fileInput.value should be DRTFakeFile. Was C:\fakepath\DRTFakeFile.

These should be PASS, not FAIL.
Comment 22 Adam Barth 2010-08-30 10:36:58 PDT
> These should be PASS, not FAIL.

Comment 23 Adam Barth 2010-08-30 12:15:49 PDT
> These should be PASS, not FAIL.

See Bug 44882.