[whatwg] access to local path in input type="file"

timeless timeless at gmail.com
Fri Mar 21 07:51:39 PDT 2008

On Fri, Mar 21, 2008 at 1:58 AM, ddailey <ddailey at zoominternet.net> wrote:
> In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user
> to change the src attribute of an image based on her perusal of local file
> space. Opera 9.5 doesn't seem to allow access to the path data necessary for
> accomplishing this rollover effect, and I suspect that may be how it is
> supposed to be according to emerging standards. That is the situation when
> the HTML file is stored on localhost.

The web changed, today firefox only provides the leafname, not the
full path (this is a good thing for security/privacy reasons), and we
don't allow remote access to local content (this is a good thing).
Security Error: Content at
http://granite.sru.edu/~ddailey/imageUpload.htm may not load or link
to file://localhost/78255.png.

>  If however, one places the code on a server (see
>  http://granite.sru.edu/~ddailey/imageUpload.htm) then the program works from
>  none of the browsers. apologies in advance if I made a mistake :(
>  While I understand the possible risk of exposing a path name of the local
>  file system to script, the various use cases of allowing users to access
>  local images within HTML, the <canvas> tag and within <svg> all seem
>  self-evident to me. Is there some standard workaround to allow the user to
>  change the source of an image on a web page to one that is locally stored?

Security Error: Content at
http://www.w3.org/TR/html4/interact/forms.html may not load or link to
Error: uncaught exception: Load of file:///c:/newfeatures.png denied.

data:text/html,<img src="file:///c:/newfeatures.png">

in the modern world, you shouldn't be able to embed local images from
remote content.

if a user wants to see a preview an image they can use their os, file
picker, favorite image viewer, etc.

you can silently auto submit the image and send them back a version.

> I
>  used to have a dozen mini-apps that took advantage of the ability to do this
>  (they even used to work in Netscape 4 and IE 4), but the programs have all
>  broken in the past few years in all contexts except IE -- (for example here
>  http://granite.sru.edu/~ddailey/svg/clipembed.html where the input type=file
>  script is remarkably simple).
>  What seems odd to me is that the browsers (except Opera) all seem to expose
>  the path data to script, despite blocking the easy use of that data. Maybe
>  I'm missing something obvious.

modern browsers will not expose path, only leaf.

>  Apologies, also, if this issue has already been discussed -- my memory seems
>  never to have been what it should have been.

More information about the whatwg mailing list