Last Comment Bug 87943 - onchange handler not firing when prefill occurs
: onchange handler not firing when prefill occurs
Status: NEW
: testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 Windows NT
: -- normal with 17 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors: Olli Pettay [:smaug]
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-26 18:55 PDT by Stephen P. Morse
Modified: 2016-10-19 18:29 PDT (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (398 bytes, text/html)
2001-11-30 01:44 PST, basic
no flags Details

Description Stephen P. Morse 2001-06-26 18:55:11 PDT
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

<html>
  <body>
    <script>
      function onChangeHandler() {
        today = new Date();
        alert("onChange handler called");
      }
    </script>

    <form method="POST" action="about:blank">
      username: 
      <input name="user" type="text">
      Password:
      <input name="pswd" type="password" onChange="onChangeHandler()">
      <input type=submit value="submit">
    </form>
  </body>
</html>
Comment 1 Stephen P. Morse 2001-06-26 18:57:50 PDT
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 Stephen P. Morse 2001-06-26 18:59:30 PDT
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 basic 2001-11-30 01:29:21 PST

http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange

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 basic 2001-11-30 01:44:57 PST
Created attachment 59830 [details]
testcase
Comment 5 karnaze (gone) 2001-11-30 07:23:50 PST
-->forms
Comment 6 rods (gone) 2001-12-20 20:32:47 PST
->>
Comment 7 Alexandru Savulov 2002-01-15 16:21:05 PST
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)
Comment 8 Christopher Hoess (gone) 2004-02-07 11:36:07 PST
This is a DOM Events bug, not layout, AFAICT.
Comment 9 Marius Andreiana 2005-09-08 03:38:14 PDT
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
focus)?

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

2) Works as expected
<form>
<input type="text" name="test2" onchange="alert('b')">
<input type="button" value="Click me" 
onclick="this.form.test2.focus();this.form.test2.value='123';this.form.test2.blur();">
</form>

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

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

Thanks
Comment 10 tito 2006-11-10 08:20:49 PST
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 R.P. Aditya 2007-03-22 07:58:02 PDT
This is happening on Mac OS X through Firefox 2.0.0.3
Comment 12 Jeff06 2007-11-13 07:41:24 PST
Got the same problem on iceweasel 2.0.0.8 on Linux.
Comment 13 Ditta 2008-05-27 09:53:00 PDT
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 andrew.p.martinez 2009-08-13 08:10:13 PDT
Still an issue, would be great to get this resolved.
Comment 15 Alessandro Vernet 2010-11-26 01:37:23 PST
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:

http://avernet.blogspot.com/2010/11/autocomplete-and-javascript-change.html

Am I mistaken?
Comment 16 Ditta 2011-01-12 10:01:22 PST
@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 Alessandro Vernet 2011-01-13 16:42:17 PST
Ditta,

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.
Comment 18 Eduardo Fonseca-Born 2011-01-21 23:20:35 PST
I'm having the same issue, very dirty to workaround... it would be nice to have it fixed!
Comment 19 Serj 2011-10-08 02:13:13 PDT
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 wedi 2014-07-28 08:28:37 PDT
So it's 12 years now. Please, please do something about this issue!
Comment 21 Ian Beveridge 2014-11-18 05:46:27 PST
Now 13 years. I think we're stuck with hacky workarounds.
Comment 22 Alexandre Folle de Menezes 2016-10-19 09:02:07 PDT
This has just bitten me.  This bug is now 15 years old, and I am having to implement a hack just for Firefox.  Great.

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