This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12213 - Provide a note explaining the history of the "fakepath" stuff so people don't go WTF
Summary: Provide a note explaining the history of the "fakepath" stuff so people don't...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-01 17:48 UTC by contributor
Modified: 2011-08-04 05:03 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2011-03-01 17:48:49 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis

Comment:
What!? Is this a joke, if I get the value of an input element in 'filename'
mode, I get the filename with an extra string prepended to it, so that to use
the filename I will always have to strip the first 12 characters? That is
really messed up.

Posted from: 136.205.16.22
User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Comment 1 Tab Atkins Jr. 2011-03-01 18:06:16 UTC
No, it's not a joke.  There are compat constraints that require the value to look like a windows filepath.
Comment 2 Aryeh Gregor 2011-03-02 00:30:26 UTC
Since the original bug filer didn't make an actual request, I've taken the liberty of interpreting this as "add a note explaining the fakepath stuff".  The gist of it is that browsers originally returned the full path, but then decided that was a security vulnerability so they only wanted to return the filename, but by then there were lots of sites that would break if they didn't get a full Windows path, so browsers had to provide a fake path instead.  Typical web platform insanity.

The note should also point out that you can do input.files[0].name or whatever instead of input.value, to avoid having to strip the path (although this might not work yet in all browsers?).
Comment 3 Ian 'Hixie' Hickson 2011-05-05 19:13:22 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: There already was one but as discussed on IRC I pointed to it from the section the original reporter was reading.
Comment 4 contributor 2011-05-05 19:27:03 UTC
Checked in as WHATWG revision r6083.
Check-in comment: Add a link to the fakepath example from the fakepath impl requirement.
http://html5.org/tools/web-apps-tracker?from=6082&to=6083
Comment 5 Michael[tm] Smith 2011-08-04 05:03:03 UTC
mass-moved component to LC1