onchange event fired too late

RESOLVED WORKSFORME

Status

()

Core
Layout: Form Controls
P2
major
RESOLVED WORKSFORME
17 years ago
9 years ago

People

(Reporter: Douglas Crockford, Assigned: John Keiser (jkeiser))

Tracking

({testcase})

Trunk
mozilla1.4alpha
x86
Windows 98
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
...which is what correctly happens in my build 2001091003 of Mozilla.

Comment 3

17 years ago
Created attachment 49363 [details]
testcase

Comment 4

17 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

Comment 5

17 years ago
*** Bug 98186 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Target Milestone: --- → mozilla1.0

Comment 6

17 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

16 years ago
adding testcase keyword in order to remove from BugAThon testcase needed list.
(seems it has one already)
Keywords: testcase

Updated

16 years ago
Priority: -- → P3

Updated

16 years ago
Summary: change event fired too late → onchange event fired too late
(Assignee)

Comment 8

16 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

Updated

15 years ago
Blocks: 185701

Comment 9

13 years ago
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

13 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

11 years ago
Created attachment 290493 [details]
onchange_onsubmit.html

a test case without alert box,

Comment 12

11 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
QA Contact: vladimire → layout.form-controls

Comment 13

9 years ago
This is FIXED
But I dont know what fixed this, hence marking this as WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.