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

RESOLVED FIXED in mozilla1.7beta

Status

()

Core
DOM: Core & HTML
P2
normal
RESOLVED FIXED
17 years ago
12 years ago

People

(Reporter: Wolfgang Schwarz, Assigned: bz)

Tracking

({dom0, testcase})

Trunk
mozilla1.7beta
dom0, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 24579 [details]
testcase (just the code from above)

Comment 2

17 years ago
It's certainly not form manager so I'll try DOM 0.
Assignee: morse → jst
Component: Form Manager → DOM Level 0
QA Contact: tpreston → desale

Comment 3

17 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
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?
Assignee: jst → rods

Comment 5

17 years ago
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.
Status: NEW → ASSIGNED
Summary: onchange for input type="file" doesn't behave correctly → [FILE]onchange for input type="file" doesn't behave correctly
Keywords: dom0

Comment 6

17 years ago
see also bug 4033 (it is assigned to joki)

Updated

17 years ago
Depends on: 57770

Comment 7

17 years ago
Will look at for 0.9.1
Target Milestone: --- → mozilla0.9.1

Updated

16 years ago
Target Milestone: mozilla0.9.1 → mozilla1.0

Comment 8

16 years ago
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

16 years ago
Moving to Future
Target Milestone: mozilla1.0 → Future

Comment 10

16 years ago
adding keyword testcase.
setting priority=p3
Keywords: testcase
Priority: -- → P3

Updated

16 years ago
Priority: P3 → --

Comment 11

15 years ago
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

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

Comment 13

14 years ago
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

14 years ago
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

14 years ago
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...
Attachment #131322 - Attachment is obsolete: true

Comment 16

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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.
Created attachment 141215 [details] [diff] [review]
This fixes both testcases and the various tests I've tried with it
Assignee: rods → 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!
Attachment #141215 - Flags: superreview?(peterv)
Attachment #141215 - Flags: review?(peterv)
Status: ASSIGNED → NEW
Priority: -- → P2
Summary: [FILE]onchange for input type="file" doesn't behave correctly → [FIX][FILE]onchange for input type="file" doesn't behave correctly
Target Milestone: Future → mozilla1.7beta
Attachment #141215 - Flags: superreview?(peterv)
Attachment #141215 - Flags: superreview+
Attachment #141215 - Flags: review?(peterv)
Attachment #141215 - Flags: review+
Summary: [FIX][FILE]onchange for input type="file" doesn't behave correctly → [FIXr][FILE]onchange for input type="file" doesn't behave correctly
Fix checked in for 1.7b
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 23

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

Comment 24

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

Comment 25

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

Comment 26

12 years ago
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.
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.
You need to log in before you can comment on or make changes to this bug.