Last Comment Bug 67873 - [FIXr][FILE]onchange for input type="file" doesn't behave correctly
: [FIXr][FILE]onchange for input type="file" doesn't behave correctly
Status: RESOLVED FIXED
: dom0, testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: P2 normal with 9 votes (vote)
: mozilla1.7beta
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Prashant Desale
:
Mentors:
: 204749 240739 243501 243898 (view as bug list)
Depends on: 57770
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-06 14:40 PST by Wolfgang Schwarz
Modified: 2006-01-17 21:15 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (just the code from above) (154 bytes, text/html)
2001-02-06 14:41 PST, Wolfgang Schwarz
no flags Details
Adding new inputs when the present ones are full. (582 bytes, text/html)
2003-09-12 01:34 PDT, Martin van Dijken
no flags Details
Adding new inputs when the present ones are full. (582 bytes, text/html)
2003-09-12 01:42 PDT, Martin van Dijken
no flags Details
This fixes both testcases and the various tests I've tried with it (1.91 KB, patch)
2004-02-11 20:42 PST, Boris Zbarsky [:bz] (still a bit busy)
peterv: review+
peterv: superreview+
Details | Diff | Splinter Review

Description Wolfgang Schwarz 2001-02-06 14:40:05 PST
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 2001-02-06 14:41:22 PST
Created attachment 24579 [details]
testcase (just the code from above)
Comment 2 Stephen P. Morse 2001-02-06 16:43:51 PST
It's certainly not form manager so I'll try DOM 0.
Comment 3 Keyser Sose 2001-02-06 23:17:01 PST
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, jst@mozilla.com) 2001-02-06 23:44:16 PST
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) 2001-02-07 05:25:01 PST
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 2001-02-25 05:15:57 PST
see also bug 4033 (it is assigned to joki)
Comment 7 rods (gone) 2001-02-28 09:53:19 PST
Will look at for 0.9.1
Comment 8 Simon Weijgers 2001-09-26 10:41:01 PDT
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) 2001-10-29 12:33:58 PST
Moving to Future
Comment 10 Prashant Desale 2002-02-07 17:03:09 PST
adding keyword testcase.
setting priority=p3
Comment 11 Adam P 2003-03-17 13:02:14 PST
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 2003-09-10 15:38:41 PDT
*** Bug 204749 has been marked as a duplicate of this bug. ***
Comment 13 Martin van Dijken 2003-09-12 01:34:57 PDT
Created attachment 131321 [details]
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 2003-09-12 01:42:19 PDT
Created attachment 131322 [details]
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 2003-09-12 01:44:12 PDT
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 2003-09-13 08:15:26 PDT
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 2003-10-15 22:24:47 PDT
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 2003-10-16 00:22:02 PDT
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 2003-10-16 01:21:15 PDT
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 [:bz] (still a bit busy) 2004-02-11 20:42:25 PST
Created attachment 141215 [details] [diff] [review]
This fixes both testcases and the various tests I've tried with it
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2004-02-11 20:49:43 PST
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 [:bz] (still a bit busy) 2004-02-19 16:33:54 PST
Fix checked in for 1.7b
Comment 23 José Jeria 2004-04-16 17:37:39 PDT
*** Bug 240739 has been marked as a duplicate of this bug. ***
Comment 24 Bill Mason 2004-05-13 06:17:44 PDT
*** Bug 243501 has been marked as a duplicate of this bug. ***
Comment 25 Bill Mason 2004-05-18 01:40:19 PDT
*** Bug 243898 has been marked as a duplicate of this bug. ***
Comment 26 Boris Aranovi&#269; 2006-01-17 08:14:18 PST
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 [:bz] (still a bit busy) 2006-01-17 08:53:23 PST
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.

Note You need to log in before you can comment on or make changes to this bug.