67873 - [FIXr][FILE]onchange for input type="file" doesn't behave correctly

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Wolfgang Schwarz]

I'm not sure if this is DOM 0 or Form Manager.

In a FileUpload field, I would excpect onchange to fire after a new file has 
just been selected. But if I change the selected file by means of the 
"Browse..." button, this is not what happens.
Example (tested with M0.7 and NB2001012020/win98):

<form name="form1">
<input type="file" size="50" name="myUploadObject" 
   onchange="alert('onchange fired')">
</form>

Two things are going wrong:

(1) If I choose a file nothing happens until the text field blurs. This happens 
when I press "Browse..." again. The result is that onchange fires _before_ a new 
file is selected. 
This could be improved if after a file is selected the form field is 
automatically blurred and the "Browse..." button focussed. That would cause 
onchange to fire after a new selection has been made, as I would expect it to 
do.

(2) onchange fires only every second time the file is changed with the 
"Browse..." button. Try this:
- Load the attachment
- Hit "Browse..." and select a file
- Hit "Browse..." again (onchange now fires) and select a different file
- Hit "Browse..." again (onchange does NOT fire) and select another file
- Hit "Browse..." again (onchange now fires) and select another file
- Hit "Browse..." again (onchange does NOT fire) and select another file
and so on.

Comment 1

[Wolfgang Schwarz]

Attachment: testcase (just the code from above)

Comment 2

[Stephen P. Morse]

It's certainly not form manager so I'll try DOM 0.

Comment 3

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001020512

For me it never fires at all...I suspect this might be event handling but i will
let someone in DOM Level 0 move it there if so.

Comment 4

[Johnny Stenback (:jst)]

Rods, sounds like one more of the onchange-fires-before-element-state-changes
bugs you've fixed in the past, could you have a look?

Comment 5

[rods (gone)]

According to the DOM Level 2 spec, the change event is only suppose to fire when  
the file input loses focus and the value has changed since it got focus:
http://www.w3.org/TR/2000/CR-DOM-Level-2-20000510/events.html#Events-eventgroupi
ngs-htmlevents

I don't think it is suppose to fire an onchange event as soon as you select a 
new value from the browse button.

My guess here is that the Browse and text field in the file input are "stealing" 
focus from each other and it is probably the text field that is sending the 
onchange event.

Comment 6

[Fabian Guisset]

see also bug 4033 (it is assigned to joki)

Comment 7

[rods (gone)]

Will look at for 0.9.1

Comment 8

[Simon Weijgers]

I'd just like to comment that MSIE 5.5 does fire an onChange event after having
selected a file using the Browse... button.

I for one just ran into this problem as well, so it seems to me that the right
thing to do is to fire an onchange event.

Just my 2 cents.

Comment 9

[rods (gone)]

Moving to Future

Comment 10

[Prashant Desale]

adding keyword testcase.
setting priority=p3

Comment 11

[Adam P]

I'm finding that onChange only fires when the contents of the Browse box are
changed by typing in the text field and switching focus from that field. 
Changing it's contents by actually browsing for a file does not fire the
onChange, even if the box loses focus.

Comment 12

[Paul LeBeau]

*** Bug 204749 has been marked as a duplicate of this bug. ***

Comment 13

[Martin van Dijken]

Attachment: Adding new inputs when the present ones are full.

One of the very good applications of the onchange event for file inputs, is
adding new ones when the old ones are already filled. Now I can see why this
bug is not a blocker for any release, but it does seem that this page is a very
well working example of a real-life situation that could really use a fix for
this.

Comment 14

[Martin van Dijken]

Attachment: Adding new inputs when the present ones are full.

I can see why this bug is not a blocker for any release, but it does prevent us
DHTML-freaks to create some interesting uses for file inputs. A colleague has
created a page that works excellently in IE, but does not do anything in Moz
unless the user actually types in the file location (I don't know ANYBODY who
does that). It seems to me this is a very realworld scenario where the onchange
on file's is really necessary. The bug has my vote.

Comment 15

[Martin van Dijken]

Comment on attachment 131322 [details]
Adding new inputs when the present ones are full.

Sorry for the spam, the form wasn't responding and I was a little impatient
after 5 minutes...

Comment 16

[Wilko de Jong]

I like to have my scripts run in Mozilla. Due to this bug I am unable to 
implement a new script I wrote in Mozilla. Please fix this bug. Thanks!


<html>
 <head>
 
 <script>
 function doit(obj) {
  var parent = obj.parentNode;
  var id = eval(obj.id) + 1;
  var y = document.createElement('input');
  y.setAttribute('id', id);
  y.setAttribute('type', 'file');
  y.setAttribute('onchange', 'doit(this)');
  parent.appendChild(y);
  parent.appendChild(document.createElement("BR"));
  // Remove the old onchange
  obj.setAttribute('onchange', 'void(0)');
 }
 </script>
 </head>
 
 <body>
 <form name="form">
 <input id="1" type="file"><br>
 <input id="2" type="file"><br>
 <input id="3" type="file" onchange="doit(this)"><br>
 </form>
 
 </body>
 </html>

Comment 17

[Kevin Ar18]

Comment #5 is correct.  onchange is only supposed to be triggered after the
"control" loses focuse AND if the "control's" value has changed.  Thus, onchange
is actually working according to specs as it is now.  To not do this would be to
break specs!  (This of course, doesn't negate the fact that I think this was a
poor design choice by W3C, and I do not think they should have made it wait
until focus is lost till it gets triggered.  However it is the spec, nonetheless.)

The specific wording is as follows:
The onchange event occurs when a control loses the input focus and its value has
been modified since gaining focus. This attribute applies to the following
elements: INPUT, SELECT, and TEXTAREA.
http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.3
and
http://www.w3.org/TR/2000/CR-DOM-Level-2-20000510/events.html#Events-eventgroupings-htmlevents

Comment 18

[Martin van Dijken]

I agree that comment 5 probably is correct, however both parts of the spec you
quote refer to inputs, selects and textareas. It is very unnatural for a
programmer to define an input type="file" and then have to work with two
different controls created from that.

On another note, I found that there is a possible workaround. It is possible for
a JS programmer to use onclick and determine yourself if the value has changed.
This is a lot more cumbersome of course and programmers mainly targeting IE will
definitely not go for the hassle, making Mozzie lose in another area...

Comment 19

[Jesse Ruderman]

Kevin: IMO, the spec is wrong to say that onchange should never fire before the
element loses focus.  For example, selecting an item from a dropdown SELECT with
the mouse fires onchange immediately in every browser, even though the dropdown
still has focus.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Attachment: This fixes both testcases and the various tests I've tried with it

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141215 [details] [diff] [review]
This fixes both testcases and the various tests I've tried with it

peterv, I choose you!

Comment 22

[Boris Zbarsky [:bzbarsky]]

Fix checked in for 1.7b

Comment 23

[José Jeria]

*** Bug 240739 has been marked as a duplicate of this bug. ***

Comment 24

[Bill Mason]

*** Bug 243501 has been marked as a duplicate of this bug. ***

Comment 25

[Bill Mason]

*** Bug 243898 has been marked as a duplicate of this bug. ***

Comment 26

[Boris Aranovič]

I am not so sure the problem is entirely solved, even if it has been solved for File Inputs.
I have a case where I have a Text Input which fires onChange event whenever it gets some sort of focus either by Tabbing to it, or by element.focus() statement. Mouseclicking on it though, does not trigger the onChange event.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Not a file input means it's a different bug.  File said bug, please, cc me, and attach your testcase.  Please make sure it's a problem in a current build first, though.