onChange in <input type="file"...>

[Tim Slattery]

I'm trying to handle the onChange event in an <input type="file">
element. In IE, there's no problem: the event fires when a file in the
"open" box is doubleclicked, or the "Open" button in the box is
clicked, or "Enter" is hit in the attached text box. I can get the
value of the element.

But in Netscape 7, onChange doesn't fire until focus leaves the
element. When you double-click a file name or click "open" in the Open
box, the filename appears in the text box, but nothing happens. When
focus leaves the text box, the event fires, but the "value" attribute
of the item has NO VALUE!!!

I wish I could tell you what Firefox does, but we're not allowed to
use Firefox here (even though we're making web systems for the general
public to use!! Don't get me started....)

So what do I have to do to properly catch this event in Gecko
browsers?

--
Tim Slattery
Sl********@bls.gov
http://members.cox.net/slatteryt

[noagbodjivictor]

Hi Tim,

If I remember correctly, you are getting the correct bihaviour with
Netscape. IE is screwing up.
onChange applies when focus is lost and value is changed.

There is a way you can simulate it using onBlur and checking is value !
= '';

[Randy Webb]

Tim Slattery said the following on 5/31/2007 2:19 PM:

I'm trying to handle the onChange event in an <input type="file">
element. In IE, there's no problem: the event fires when a file in the
"open" box is doubleclicked, or the "Open" button in the box is
clicked, or "Enter" is hit in the attached text box. I can get the
value of the element.

But in Netscape 7, onChange doesn't fire until focus leaves the
element.

What version of NS7? In NS 7.2 it fires the onchange as soon as I choose
a file and dismiss the file dialog box.

When you double-click a file name or click "open" in the Open
box, the filename appears in the text box, but nothing happens. When
focus leaves the text box, the event fires, but the "value" attribute
of the item has NO VALUE!!!

I can't reproduce that behavior. It my be a version of NS7 that doesn't
allow the reading of file input values by script for some obscure NS/AOL
reason. I tested it both locally and on a live server and get the same
results - I get the value. That leads to thinking something else in your
code is causing NS7 to bonkers out on you.

I wish I could tell you what Firefox does, but we're not allowed to
use Firefox here (even though we're making web systems for the general
public to use!! Don't get me started....)

<input type="file" onchange="alert(this.value)">

IE7, Opera9, NS8, NS7.2, FF1.5 and FF2.0 all behave the same for me.
They all alert the file name as soon as the File Dialog window is
dismissed and the value of the input has been set.

The only difference I see in what is being alerted is whether it gives
the full path to the file or not. FF, NS and IE give me full paths.
Opera gives me just the file name. Whether IE7 gives the full path or
just the file name is a user setting though.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[noagbodjivictor]

Hi Tim,

If I remember correctly, you are getting the correct bihaviour with
Netscape. IE is screwing up.
onChange applies when focus is lost.

[Randy Webb]

no*************@gmail.com said the following on 5/31/2007 6:30 PM:

Hi Tim,

This is not email, so I am not Tim. Please quote what you are replying to.

If I remember correctly, you are getting the correct bihaviour with
Netscape. IE is screwing up.

IE doesn't fire the onchange when the element is set, it is firing it
after it has changed and clicking in the File Dialog box is causing the
input to lose focus (an alert does the same thing).

onChange applies when focus is lost.

Nobody said any differently.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Sutabi]

You can setup an interval with the onclick of "browse" input. In your
interval simply check for the value of the "browse" input value.
On May 31, 3:35 pm, Randy Webb <[e-mail]:

[e-mail] said the following on 5/31/2007 6:30 PM:

Hi Tim,

This is not email, so I am not Tim. Please quote what you are replying to.

If I remember correctly, you are getting the correct bihaviour with
Netscape. IE is screwing up.

IE doesn't fire the onchange when the element is set, it is firing it
after it has changed and clicking in the File Dialog box is causing the
input to lose focus (an alert does the same thing).

onChange applies when focus is lost.

Nobody said any differently.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/

[Tim Slattery]

Randy Webb <Hi************@aol.comwrote:

>I can't reproduce that behavior. It my be a version of NS7 that doesn't
allow the reading of file input values by script for some obscure NS/AOL
reason. I tested it both locally and on a live server and get the same
results - I get the value. That leads to thinking something else in your
code is causing NS7 to bonkers out on you.

Geez...this morning I can't reproduce it either. It still doesn't fire
in NS (7.02, by the way) until focus goes someplace else, but then it
seems to work properly. I kind of understand that, but it's
inconvenient.

I'm using a nifty Javascript from www.the-stickman.com (it was
mentioned in this group at one time), that allows selecting multiple
files in an HTML page. When the user uses and assigns a value to an
<input type="file" ...element, the onchange handler hides that
element and creates a new one. It also adds a line to a list of
selected files elsewhere on the page. So, although you can select only
one at a time, you can do that over and over to get as many as you
want.

This is working fine in IE. All the hidden <input type="file"...>
elements result in files being sent to the server. In NS7.02, for some
reason, all the hidden <input type="file"...elements have no value
and nothing gets sent to the server. (Verified by looping through all
these elements when the form is submitted, and using "alert" to show
their value.)

So I made a little, simple test case and got the bogus results I
reported earlier.

The hiding is actually done by moving the element way off the left
edge of the page (this.style.left="-1000px";). The comment at that
point says it doesn't use display:none because Safari doesn't like it.

But I can't figure out why the elements lose their value in NS. Maybe
it's a bug that's been fixed since.

--
Tim Slattery
Sl********@bls.gov
http://members.cox.net/slatteryt

[Randy Webb]

Tim Slattery said the following on 6/1/2007 10:30 AM:

Randy Webb <Hi************@aol.comwrote:

<snip>

The hiding is actually done by moving the element way off the left
edge of the page (this.style.left="-1000px";). The comment at that
point says it doesn't use display:none because Safari doesn't like it.

But I can't figure out why the elements lose their value in NS. Maybe
it's a bug that's been fixed since.

Try leaving them visibly on the page and see if NS will retain the
values. If it does, then you know where to start looking for it. NS may
not like you moving File Controls off the screen and for some bonkers
reason it resets the value.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/