By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,667 Members | 2,073 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,667 IT Pros & Developers. It's quick & easy.

Display File Selection Window

P: n/a
Is there a way to display the file selection window for a file input
field via JavaScript? My goal is to emulate the behavior seen in
Yahoo! Mail BETA. When adding an attachment, it displays a file
selection window when you click a custom button/icon. I saw an example
of using CSS to actually position the browse button behind an image. I
am hoping that isn't the only option.

Nov 15 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
VK
Is there a way to display the file selection window for a file input
field via JavaScript?
In the default security environment no, it is not possible (unless some
unknown to me security exploit in some browser).

Nov 15 '06 #2

P: n/a
VK said the following on 11/15/2006 5:25 PM:
>Is there a way to display the file selection window for a file input
field via JavaScript?

In the default security environment no, it is not possible (unless some
unknown to me security exploit in some browser).
<form id="myForm">
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
</form>

IE only.

Now, please explain how that is a "security exploit".

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 15 '06 #3

P: n/a
ASM
Matt a écrit :
Is there a way to display the file selection window for a file input
field via JavaScript?
No you can't (except with IE Windows ? with ActiveX ?) display on your
page a copy of your system files selector.

The input 'file' naturally shows a default button to give access to this
selector's system.
My goal is to emulate the behavior seen in
Yahoo! Mail BETA.
url to see what you talk about ... ?
When adding an attachment, it displays a file
selection window when you click a custom button/icon.
You have any possibility to change this button which doesn't appear the
same on different browsers or/and different systems (Win, Mac, Linux
....) or/and different languages (fr, en, ur, ...).

The idea to use an image and css to cover this button seems to be quite
good. (what is the url to see this presentation ?)

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Nov 16 '06 #4

P: n/a
ASM
Randy Webb a écrit :
>
Now, please explain how that is a "security exploit".
You did give the answer ... IE only ... !

However, code bellow works also with Safari 1.3 and iCab 3
(Opera cries to a violation of security, Firefox does nothing)

<html>
<form name="myForm" style="visibility:hidden;" action="test.htm"
method="post">
<input type="file" name="myFileInput">
</form>
<form>
<input type="image" src="file_button.jpg" style="width:70px;"
onclick="document.myForm.myFileInput.click();">
</form>
</html>

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Nov 16 '06 #5

P: n/a
VK

Randy Webb wrote:
<form id="myForm">
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
</form>

IE only.

Now, please explain how that is a "security exploit".
There are "technical exploits" and "human factor exploits".
A technical exploit with type="file" was for example (for several years
on "some well-known UA", fixed now):

objectInputType.value = "C:\\WINDOWS\\Cookies\\index.dat";
objectForm.submit();

That answers btw recent questions "why these nasty UA's do not let me
to set/read path strings in input type="file")

The exploit you just listed is "human factor"-based one. It allows to
disassemble (in the user mind) the file dialog popup and the current
form navigation. All we need atop is some full DHTML-based visual
emulation of ActiveX security dialog from say "Microsoft, Inc." where
the automatic upload window will be a part of "Microsoft, Inc. security
surway/update/request".

The UA's really concerned about user's security have locked this
exploit long ago; because as Kevin Mitnick has proved long time ago, in
the human-computer system the most vulnerable part is always human,
rarely computer.

Nov 16 '06 #6

P: n/a
VK
VK wrote:
The UA's really concerned about user's security have locked this
exploit long ago; because as Kevin Mitnick has proved long time ago, in
the human-computer system the most vulnerable part is always human,
rarely computer.
Both IE and FF have ready to use file access tools: where FF even have
the "all times dream" multi-select File Open dialog. Anyone feel free
to use - after signing your ActiveX / JAR properly. If your company
cannot provide the required credentials to a certificate authority, or
if $300-$600 goes beyond your company budget: in this case sorry but
your company did not get yet the needed level to mess up with local
file systems. Come back one year later :-)

Nov 16 '06 #7

P: n/a
Unless anyone else has an idea, it looks like using an image to cover
the real button would be my only option. The link to the article where
I found this solution is:

http://www.quirksmode.org/dom/inputfile.html

I don't really want this to come accross as an endorsement, but someone
asked for a link to the program I was referring to. Yahoo! Mail can be
accessed at:

http://mail.yahoo.com/

You will need a Yahoo! account and will need to switch to the BETA
version of their webmail once you sign on. The attachment feature of
the current version doesn't have the behavior described.

Thanks for all the input.

Nov 16 '06 #8

P: n/a
ASM said the following on 11/16/2006 3:21 AM:
Randy Webb a écrit :
>>
Now, please explain how that is a "security exploit".

You did give the answer ... IE only ... !
Being "IE only" code doesn't make it a "security exploit". For it to be
an exploit, you have to show how you can get around default security by
being able to programatically click that button.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 16 '06 #9

P: n/a
VK said the following on 11/16/2006 6:08 AM:
Randy Webb wrote:
><form id="myForm">
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
</form>

IE only.

Now, please explain how that is a "security exploit".

There are "technical exploits" and "human factor exploits".
You said "security exploit" and I am challenging you, once again, to
show an exploit by being able to programatically click the input button.
A technical exploit with type="file" was for example (for several years
on "some well-known UA", fixed now):
Then it isn't an exploit anymore, you are talking about a fixed security
issue.
objectInputType.value = "C:\\WINDOWS\\Cookies\\index.dat";
objectForm.submit();
Yes, and it was fixed by not allowing the setting of a file input's
value. And it has *nothing* to do with the question at hand.
That answers btw recent questions "why these nasty UA's do not let me
to set/read path strings in input type="file")
You can't set it but you *can* read it.
The exploit you just listed is "human factor"-based one. It allows to
disassemble (in the user mind) the file dialog popup and the current
form navigation. All we need atop is some full DHTML-based visual
emulation of ActiveX security dialog from say "Microsoft, Inc." where
the automatic upload window will be a part of "Microsoft, Inc. security
surway/update/request".
And I can do that without clicking the button. Again, you aren't
answering my question. Yet you are avoiding it.
The UA's really concerned about user's security have locked this
exploit long ago; because as Kevin Mitnick has proved long time ago, in
the human-computer system the most vulnerable part is always human,
rarely computer.
You still haven't answered my question. I want you to take the code I
posted and show the "security vulnerability" in it. If you can do that,
then I will openly admit to being wrong. Until then, you are just VK'ing
as you normally do.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 16 '06 #10

P: n/a
ASM
Randy Webb a écrit :
ASM said the following on 11/16/2006 3:21 AM:
>Randy Webb a écrit :
>>>
Now, please explain how that is a "security exploit".

You did give the answer ... IE only ... !

Being "IE only" code doesn't make it a "security exploit". For it to be
an exploit, you have to show how you can get around default security by
being able to programatically click that button.
Anyway It was IE "only" because you called an element by its id that it
hasn't (calling the form by its name would have to run on correct browser)

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Nov 16 '06 #11

P: n/a
ASM said the following on 11/16/2006 6:26 PM:
Randy Webb a écrit :
>ASM said the following on 11/16/2006 3:21 AM:
>>Randy Webb a écrit :

Now, please explain how that is a "security exploit".

You did give the answer ... IE only ... !

Being "IE only" code doesn't make it a "security exploit". For it to
be an exploit, you have to show how you can get around default
security by being able to programatically click that button.

Anyway It was IE "only" because you called an element by its id that it
hasn't (calling the form by its name would have to run on correct browser)
I classified it as "IE only" because IE is the only browser - on a PC -
that will invoke the File Dialog window by programatically using
..click() on the input button.

As for the form element not having a name - its not required and there
are even DTD's that forbid the NAME attribute in HTML4.01:

<URL:
http://groups-beta.google.com/group/comp.lang.javascript/browse_thread/thread/a92d0950c384edd5/415c48330379191d?lnk=gst&q=Randy+Webb+Lasse+Form+I D+Name&rnum=4#415c48330379191d>

Read the very end of that thread, the last two or three posts between
myself and Michael Winter.

If what you are saying is true then any non-IE browser should give the
error message of something along the lines for document.forms.formID has
no properties and I do not get those errors in Opera or FF, do you get
them in mac browsers?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 17 '06 #12

P: n/a

Randy Webb wrote:
ASM said the following on 11/16/2006 6:26 PM:
[...]
Anyway It was IE "only" because you called an element by its id that it
hasn't (calling the form by its name would have to run on correct browser)
[...]
If what you are saying is true then any non-IE browser should give the
error message of something along the lines for document.forms.formID has
no properties
Your code was:

<form id="myForm">
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
</form>

I think Stephanie is referring to the fact that if the button is
outside the form then the 'no properties' error occurs in both IE and
Firefox. If it's inside the form, IE and Fx are OK but Opera still
barfs.

I don't have access to Mac browsers right now, I'll check later.
--
Rob

Nov 17 '06 #13

P: n/a
ASM
Randy Webb a écrit :
ASM said the following on 11/16/2006 6:26 PM:
>>
Anyway It was IE "only" because you called an element by its id that
it hasn't (calling the form by its name would have to run on correct
browser)

As for the form element not having a name - its not required and there
are even DTD's that forbid the NAME attribute in HTML4.01:
Probably, but the subject is not there ...
Do I write so ugly english you can't understand what I mean ?
I classified it as "IE only" because IE is the only browser - on a PC -
that will invoke the File Dialog window by programatically using
.click() on the input button.
I haven't a PC Win, but did you try with a correct JS call ?
(byId)
If what you are saying is true then any non-IE browser should give the
error message of something along the lines for document.forms.formID has
no properties
My IE, my FF, and my Opera do that : error message
and I do not get those errors in Opera or FF,
Please test it again with your code whom copy here :

<form id="myForm">
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
</form>
do you get them in mac browsers?
Absolutely !

Some of them submit the form
(job of any button in a form which isn't a reset)

See complete tests in my next answer to RobG.
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Contact : http://stephane.moriaux.perso.wanadoo.fr/contact
ASM = Aimable Stéphane Moriaux = Amateur Sasseur Merdouilles
Nov 17 '06 #14

P: n/a
ASM
RobG a écrit :
Randy Webb wrote:
>ASM said the following on 11/16/2006 6:26 PM:
[...]
>>Anyway It was IE "only" because you called an element by its id that it
hasn't (calling the form by its name would have to run on correct browser)
[...]
>If what you are saying is true then any non-IE browser should give the
error message of something along the lines for document.forms.formID has
no properties

Your code was:

<form id="myForm">
notice : the form has *NO name*
<input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>
notice 2 : the form is called by ist *name*
</form>

I think Stephanie is referring to the fact that if the button is
outside the form then the 'no properties' error occurs in both IE and
Firefox. If it's inside the form, IE and Fx are OK but Opera still
Even if button is inside the form, my FF is not OK :
"Erreur : document.myForm has no properties"
said its console
As my IE does it too :
"document.myForm is not an object"

Of course : the form is not named.

In my Firefox any button will submit the form independently of its type.
iCab confirm this feature showing in its status bar :
"Send the form"
while you fly over this button.
Opera 9 does something similar (in status bar)

Safari 1.3.2 (which I think not to be a real good browser) :
- open the File selector
- *and* during this time submit the form ... ! ! :-(

I don't have access to Mac browsers right now, I'll check later.
With this code :
<form name="thisForm" action="test.htm" method="post"
enctype="multipart/form-data">
<input type="file" name="myFileInput">
<a href="#"
onclick="document.thisForm.myFileInput.click(); return false;">Test</a>
<input type=submit value=go>
</form>

FF and Opera don't move.
Safari and iCab try to do what is asked (file selector).

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Nov 17 '06 #15

P: n/a
ASM said the following on 11/17/2006 4:59 AM:
RobG a écrit :
>Randy Webb wrote:
>>ASM said the following on 11/16/2006 6:26 PM:
[...]
>>>Anyway It was IE "only" because you called an element by its id that it
hasn't (calling the form by its name would have to run on correct
browser)
[...]
>>If what you are saying is true then any non-IE browser should give the
error message of something along the lines for document.forms.formID has
no properties

Your code was:

<form id="myForm">

notice : the form has *NO name*
Correct.
> <input type="file" name="myFileInput">
<button onclick="document.myForm.myFileInput.click()">Test </button>

notice 2 : the form is called by ist *name*
No, it was called using it's ID attribute because, as you noted, it has
no name attribute.
> </form>

I think Stephanie is referring to the fact that if the button is
outside the form then the 'no properties' error occurs in both IE and
Firefox. If it's inside the form, IE and Fx are OK but Opera still
Moving the button outside the form, I get the errors. Odd.
Even if button is inside the form, my FF is not OK :
"Erreur : document.myForm has no properties"
said its console
As my IE does it too :
"document.myForm is not an object"

Of course : the form is not named.
With an ID, I don't get errors in IE7 with the button inside the form.
Nor with Opera or FF2.0. Moving the button outside the form does give
the errors.

It is odd behavior to say the least as whether the button is in the form
or not shouldn't affect it looking it up via ID unless somehow IE is
putting the form in the scope chain when the button is in the form but
not when it's outside leaving it able to find it <shrug>.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 17 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.