Closed Bug 87943 Opened 23 years ago Closed 8 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
(deleted), 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) (deleted) —
-->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
Attached file More compatible testcase (deleted) —
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: 8 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: