Javascript events on two different form elements are executing concurrently

NEW
Unassigned

Status

()

Core
Event Handling
16 years ago
8 years ago

People

(Reporter: Ryan Gustafson, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3)
Gecko/20020523
BuildID:    2002052306

I've noticed that the onchange() events on a textbox can fire conccurently with
onclick() events on an image.

This causes problems when the onchange() event for the textbox modifies
important values on the form, and the onclick() event causes the browser to
submit the form.  The values submitted for the form are incorrect (because the
onchange() code had not finished executing).

So far, I only seem to be able to get this to happen when an alert dialog
appears.  Either one created by me programatically, or one the browser decides
to create (say because of CPU hogging code).

In IE this is not a problem.  The onchange() fires to completion first.

Reproducible: Always
Steps to Reproduce:
I have a sample HTML showing the problem.

Actual Results:  The onclick() event firsts before the onchange() event has
completed.

Expected Results:  The onclick() event should not fire until the onchange()
event is completed.
(Reporter)

Comment 1

16 years ago
Created attachment 88345 [details]
bug test HTML

Comment 2

16 years ago
Browser, not engine ---> Event Handling

Confirming reported behavior with Mozilla trunk binary 2002061707 on WinNT.
IE6 and Mozilla behave differently on the testcase -
Assignee: rogerl → joki
Component: JavaScript Engine → Event Handling
QA Contact: pschwartau → rakeshmishra

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

15 years ago
QA Contact: rakeshmishra → trix

Updated

15 years ago
Keywords: testcase

Comment 3

14 years ago
.
Assignee: joki → saari
QA Contact: trix → ian
It looks like the click handler just fires before the change handler.  I think
the sequence of events is as follows:

1)  Click happens.  Click handlers fire.
2)  Click is not cancelled, so it leads to a focus change; focus handlers fire
3)  An input losing focus checks whether its value changed and fires onchange.

Which part do you think should be different?
Whiteboard: DUPEME

Comment 5

11 years ago
The bug is still present with firefox 1.5.0.4

Comment 6

11 years ago
(In reply to comment #4)
> 1)  Click happens.  Click handlers fire.
> 2)  Click is not cancelled, so it leads to a focus change; focus handlers fire
> 3)  An input losing focus checks whether its value changed and fires onchange.
> 
> Which part do you think should be different?

I think that the check of the value of the input losing its focus should be run before interpreting the clicks. What I mean is:

1) The user clicks
2) All the other inputs lose their focuses, forcing them to handle "onchange" (and probably "onblur") events.
3) If any "onchange" (or "onblur") event has been caught, the click is cancelled, otherwise it will proceed with the "onclick" event.
> 1) The user clicks
> 2) All the other inputs lose their focuses, forcing them to handle "onchange"
> (and probably "onblur") events.

Is that what IE does?  I'd think that preventDefault() on the click would prevent the focus changes...

What do Opera and Safari do?
Created attachment 229967 [details]
testcase2

Same testcase, but simpler (for me at least).
Current Firefox trunk build acts the same as IE6 when following the steps in the testcase -> alert("onchange fired"); is fired, nothing else.
Assignee: saari → events
Er.... shouldn't there be two alerts no matter what?
(In reply to comment #9)
> Er.... shouldn't there be two alerts no matter what?

Well, maybe, but that's not what's currently happening with testcase2 in IE6, Opera9 or Firefox.

Assignee: events → nobody
QA Contact: ian → events
You need to log in before you can comment on or make changes to this bug.