onchange handler not firing when prefill occurs




DOM: Core & HTML
16 years ago
6 months ago


(Reporter: Stephen P. Morse, Unassigned, Mentored)



Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



16 years ago
Save the html shown below to a file
Enter the file name in the browser's url bar
Fill in username and password
Press submit
You get two dialogs, one saying that onChangeHandler was called and the other
   asking if you want to save the password
Dismiss the informative dialog that said that onchange hander was called
Answer yes to the other dialog indicating that you want the password saved

Enter the filename again in the browser's url bar
Form will come up prefilled by the password manager
Press submit
The dialog about the onchange handler never appears

I'll explain why I believe that this is a bug in my next comment

      function onChangeHandler() {
        today = new Date();
        alert("onChange handler called");

    <form method="POST" action="about:blank">
      <input name="user" type="text">
      <input name="pswd" type="password" onChange="onChangeHandler()">
      <input type=submit value="submit">

Comment 1

16 years ago
This is a problem because a page like http://webmail.rpi.com uses the onchange 
handler to initialize another field which will get passed as a POST parameter 
back to the site.  So if the password field is never filled in manually, this 
value doesn't go back to the server and the login fails.

I believe that in this case the onchange handler should fire when the form is 
initially layed out because the value is changing from nothing to some prefilled 
value as determined by the password manager.

Comment 2

16 years ago
oops, disregard "today=new Date" in the example code above.  That was part of 
the code on the original site which I forgot to remove when simplifying it for 
this bug report.

Comment 3

16 years ago


onchange = script [CT]
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.

Comment 4

16 years ago
Created attachment 59830 [details]

Comment 5

16 years ago
Assignee: karnaze → rods
Component: Layout → HTML Form Controls
QA Contact: petersen → madhur

Comment 6

16 years ago
Assignee: rods → alexsavulov

Comment 7

16 years ago
I'll take a look when I get some time.

(the ideea of updating some value that's going to be submitted when a field
changes is weak. what use does it makes i.e. when the field last changed 11:58pm
and the submit occurs 12:03am in the case of a date? onsubmit would be here much
more suitable)
Target Milestone: --- → Future
Keywords: testcase
This is a DOM Events bug, not layout, AFAICT.
Assignee: alexsavulov → events
Component: Layout: Form Controls → DOM: Events
QA Contact: madhur → ian

Comment 9

12 years ago
According to comment #3, onChange shouldn't trigger in this case? Or the
password manager works by javascript (set focus to element, update value, leave

What about these testcases?
1) It doesn't work now, should it? Is there an alternative to detect change in
this case?
<input type="text" name="test2" onchange="alert('b')" >
<input type="button" value="Click me"  onclick="this.form.test2.value='123'">

2) Works as expected
<input type="text" name="test2" onchange="alert('b')">
<input type="button" value="Click me" 

3) With element disabled, it doesn't work anymore, which is ok according to spec.
<input type="text" name="test2" onchange="alert('b')" disabled="disabled">
<input type="button" value="Click me" 

So, is there an alternative to detect change in 1) which would also work with
disabled elements?


Comment 10

11 years ago
Take an INPUT widget, with lot of prefill value (like aa, aab, aabbcc)
Type aa, and Firefox automatilly prepared the next possible value.
Type on Enter to select it, and leave field.

-> OnChange() never call.

In this case, the value have change when we leave field. 

So, it's really a bug.

Comment 11

11 years ago
This is happening on Mac OS X through Firefox

Comment 12

10 years ago
Got the same problem on iceweasel on Linux.

Comment 13

9 years ago
The problem still exists. When typing text in an INPUT[text] and leaving the field  the onChange event is called.
When changing the text by selecting an item from the prefill-drowdown-list and then pressing TAB or ENTER, the event is NOT called (i.e. the new value is definitely different from the one before, regardless if the old value was empty or a value).
This is also true when using the mouse (either for selecting the value or leaving the field, neither way the event is triggered).

This is definitely a bug in my opinion and should be fixed. Can anyone comment on this, if and when this will be fixed?

Comment 14

8 years ago
Still an issue, would be great to get this resolved.
Assignee: events → nobody
QA Contact: ian → events

Comment 15

7 years ago
Is this really a bug? Based on my understanding of the HTML 4.01 and HTML5 specifications, the way Firefox behaves is inline with what the specifications says. See the discussion under "The HTML Specification" at:


Am I mistaken?

Comment 16

7 years ago
@Allessandro: yes, you are definitely mistaken.

FF 3 neither behaves according to HTML spec 4.01 nor 5.
However you interpret 4.01 there should be no doubt that the change event should be called when leaving the field. As comments 10 and 13 (maybe some others) show, this is not the case under certain circumstances.
In my opinion HTML 5 is even more clear about this and defines that the change event should be triggered even without leaving the field but by just selecting a value from the prefill drop-down. And this is never the case for FF 3.

For FF 4 I do not know, so maybe this is solved then.

Comment 17

7 years ago

With Firefox 4, when users select a value from a list of suggestions, the 'change' event is dispatched. So we are agreement here: based on our understanding of the spec, this is what should happen, and it is what happens. So far so good.

The other case is the fields that are pre-filled when the page is loaded, without users taking any action at the time the page is loaded. This is something that can happen for username/password fields. Here Firefox 4 does not dispatch the 'change' event. And based on my reading of the spec, the 'change' event should not be dispatched in that case (despite the fact that, as a developer, I'd like to get the 'change' event in that case too—but that's irrelevant).

So my take is that this bug should now be closed.
I'm having the same issue, very dirty to workaround... it would be nice to have it fixed!

Comment 19

6 years ago
Seriously?!?!? 9 years and still no fix? This seems like such a simple thing to fix. 1) Require DOM events to fire when Password Manager changes those fields!!!

1 simple step! Please fix, the hacky work arounds are really awful!

Comment 20

3 years ago
So it's 12 years now. Please, please do something about this issue!

Comment 21

3 years ago
Now 13 years. I think we're stuck with hacky workarounds.


3 years ago
Mentor: bugs@pettay.fi
Component: DOM: Events → DOM: Core & HTML
This has just bitten me.  This bug is now 15 years old, and I am having to implement a hack just for Firefox.  Great.

Comment 23

7 months ago
Created attachment 8838827 [details]
More compatible testcase
Attachment #59830 - Attachment is obsolete: true
Attachment #8838827 - Attachment filename: file_87943.txt → file_87943.htm
Attachment #8838827 - Attachment mime type: text/plain → text/html
(In reply to Alexandre Folle de Menezes from comment #22)
> This has just bitten me.  This bug is now 15 years old, and I am having to
> implement a hack just for Firefox.  Great.

(In reply to alex.m.sheehan from comment #23)
> Bump

This was fixed in Firefox 36 so if you're still seeing problems then please file a new bug and CC me.

Note that you can also use the `input` event to detect changes from autofill.
Last Resolved: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1077308
You need to log in before you can comment on or make changes to this bug.