Display File Selection Window

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.

Is there a way to display the file selection window for a file input

Quote:

field via JavaScript?

In the default security environment no, it is not possible (unless some
unknown to me security exploit in some browser).

VK said the following on 11/15/2006 5:25 PM:

Quote:

>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/

Matt a écrit :

Quote:

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.

Quote:

My goal is to emulate the behavior seen in
Yahoo! Mail BETA.

url to see what you talk about ... ?

Quote:

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

Randy Webb a écrit :

Quote:

>
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

Randy Webb wrote:

Quote:

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

VK wrote:

Quote:

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

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.

ASM said the following on 11/16/2006 3:21 AM:

Quote:

Randy Webb a écrit :

Quote:

>>
>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/

VK said the following on 11/16/2006 6:08 AM:

Quote:

Randy Webb wrote:

Quote:

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

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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/

Randy Webb a écrit :

Quote:

ASM said the following on 11/16/2006 3:21 AM:

Quote:

>Randy Webb a écrit :

Quote:

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

ASM said the following on 11/16/2006 6:26 PM:

Quote:

Randy Webb a écrit :

Quote:

>ASM said the following on 11/16/2006 3:21 AM:

Quote:

>>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/

Randy Webb wrote:

Quote:

ASM said the following on 11/16/2006 6:26 PM:

[...]

Quote:

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)

[...]

Quote:

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

Randy Webb a écrit :

Quote:

ASM said the following on 11/16/2006 6:26 PM:

Quote:

>>
>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 ?

Quote:

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)

Quote:

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

Quote:

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>

Quote:

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

RobG a écrit :

Quote:

Randy Webb wrote:

Quote:

>ASM said the following on 11/16/2006 6:26 PM:

[...]

Quote:

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

[...]

Quote:

>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*

Quote:

notice 2 : the form is called by ist *name*

Quote:

</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 ... ! ! :-(

Quote:

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

ASM said the following on 11/17/2006 4:59 AM:

Quote:

RobG a écrit :

Quote:

>Randy Webb wrote:

Quote:

>>ASM said the following on 11/16/2006 6:26 PM:

>[...]

Quote:

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

>[...]

Quote:

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

Quote:

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

Quote:

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

Quote:

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/

Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

re: Display File Selection Window

Similar JavaScript / Ajax / DHTML bytes

/bytes/development

/bytes/it

/bytes/about