Closed Bug 87943 Opened 23 years ago Closed 7 years ago

onchange handler not firing when prefill occurs

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1077308
Milestone:
Future

People

(Reporter: morse, Unassigned, Mentored)

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

More compatible testcase
358 bytes, text/html
Details 
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>
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.
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.

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.
Attached file testcase (obsolete) — 

    
    

    
  
-->forms
Assignee: karnaze → rods
Component: Layout → HTML Form Controls
QA Contact: petersen → madhur

    
    

    
  
->>
Assignee: rods → alexsavulov

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
This is happening on Mac OS X through Firefox 2.0.0.3

    
    

    
  
Got the same problem on iceweasel 2.0.0.8 on Linux.

    
    

    
  
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?

    
    

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

    
    

    
  
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?

    
    

    
  
@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.

    
    

    
  
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.

    
    

    
  
I'm having the same issue, very dirty to workaround... it would be nice to have it fixed!

    
    

    
  
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!

    
    

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

    
    

    
  
Now 13 years. I think we're stuck with hacky workarounds.
Mentor: bugs
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.

    
    

    
  
Bump

    
    

    
  


  

        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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: