Bug 29000 – Implement HTML5's fakepath

• Component: DOM
• Status: RESOLVED FIXED

[Adam Barth]

When you get the value property of an <input type="file">, you're supposed to get C:\fakepath\<filename> instead of just <filename>.

[Adam Barth]

Created attachment 39128 [details]
work-in-progress

[Adam Barth]

The code change looks pretty trivial.  Any hints about how to write a test?

[Adam Barth]

Created attachment 39130 [details]
patch


---
 5 files changed, 42 insertions(+), 14 deletions(-)

[Eric Seidel (no email)]

This is about the lamest thing ever.  Why oh why would HTML5 spec this?

[Eric Seidel (no email)]

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

[Eric Seidel (no email)]

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

[Sam Weinig]

I agree with Eric, this is pretty lame. Does anyone know the rationale behind the decision?

[Dimitri Glazkov (Google)]

I think it should be c:\awesomepath. /me ducks.

[Gavin Barraclough]

This is just too painfully idiotic a decision in the spec for words.
Please, please, no.

eseidel++ for the r-.

[Adam Barth]

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.

[Maciej Stachowiak]

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.

[Maciej Stachowiak]

The upshot of my comments is, I think we should just bite the pillow and get this change over with.

[Adam Barth]

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.

[Eric Seidel (no email)]

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.

[Ian 'Hixie' Hickson]

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

[Darin Adler]

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.

[Adam Barth]

Created attachment 65867 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 65867 [details]
Patch for landing

Clearing flags on attachment: 65867

Committed r66343: <http://trac.webkit.org/changeset/66343>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/66343 might have broken Qt Linux Release

[Alexey Proskuryakov]

-PASS fileInput.value is "DRTFakeFile"
+FAIL fileInput.value should be DRTFakeFile. Was C:\fakepath\DRTFakeFile.

These should be PASS, not FAIL.

[Adam Barth]

> These should be PASS, not FAIL.

Ok.

[Adam Barth]

> These should be PASS, not FAIL.

See Bug 44882.