Closed
Bug 99350
Opened 23 years ago
Closed 15 years ago
onchange event fired too late
Categories
(Core :: Layout: Form Controls, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
mozilla1.4alpha
People
(Reporter: douglas, Assigned: john)
References
Details
(Keywords: testcase)
Attachments
(2 files)
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) BuildID: 20010726 change fires AFTER submit. It needs to fire before submit, so that a script has an opportunity to validate the field before it is transmitted. Reproducible: Always Steps to Reproduce: Attach a change handler to an input. Type something into the input and submit the form. Actual Results: The form is submitted, and THEN the change event fires. Expected Results: First change, then submit.
Comment 1•23 years ago
|
||
...which is what correctly happens in my build 2001091003 of Mozilla.
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
The testcase I just attached contains event handlers onblur(attached to text field), onfocus(attached to text submit button), onchange(attached to text field), and onsubmit(attached to the form. To reproduce: 1)click on the text field 2)type something 3)click on the submit button Netscape 6: onsubmit onblur onchange onfocus IE6: onchange onfocus onblur onsubmit Netscape 4.78: onchange onblur onfocus onfocus onfocus onfocus.... I think the correct behaviour would be: onchange onblur onfocus onsubmit, same as what Netscape 4.x is suppose to be doing. At least thats what makes most sence to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Comment 6•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 7•22 years ago
|
||
adding testcase keyword in order to remove from BugAThon testcase needed list. (seems it has one already)
Keywords: testcase
Updated•22 years ago
|
Priority: -- → P3
Updated•22 years ago
|
Summary: change event fired too late → onchange event fired too late
Assignee | ||
Comment 8•22 years ago
|
||
This is highly important. onchange firing after onsubmit means many apps will have poor data integrity--they rely on onchange to set the values of other fields or validate fields. My first guess is that click does not set focus until after the click handler has bubbled to the document. That would give the behavior you see here. Focus needs to be set sooner, probably.
Assignee: joki → jkeiser
Component: DOM Events → Layout: Form Controls
Priority: P3 → P2
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
I have another testcase (http://www.annotea.org/mozilla/problems/problemonchange.xul) with a normal button and oncommand. The button is supposed to use the corrected field but that is changed only after the command has run. (linux mozilla 1.7.2 oncommand was not called at all but that has been corrected in windows firefox 1.0.1) Marja
Comment 10•19 years ago
|
||
JavaScript & DHTML Cookbook By Danny Goodman. I would expect OnChange firing after each typed character of input text element. In fact it is delayed until I click to focus another element. So I thought the following code would help. It did not try { ta.blur(); } catch(e) { } try { ta.focus(); } catch(e) {} // force an onChamge HTML code that demonstrates the problem <input type="text" name="firstName" id="ta" size="20" maxlength="25" onchange="this.value = this.value.toUpperCase( )" />
Comment 11•17 years ago
|
||
a test case without alert box,
Comment 12•17 years ago
|
||
I think this got fixed. And hence can be closed original test case attachment 49363 [details], had extra side effect due to the alert calls. but in attachment 290493 [details], I get events in expect order, ie Events : onChange onBlur onFocus onSubmit
Updated•15 years ago
|
QA Contact: vladimire → layout.form-controls
Comment 13•15 years ago
|
||
This is FIXED But I dont know what fixed this, hence marking this as WORKSFORME
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•