152926 - Javascript events on two different form elements are executing concurrently

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ryan Gustafson]

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.

Comment 1

[Ryan Gustafson]

Attachment: bug test HTML

Comment 2

[Phil Schwartau]

Browser, not engine ---> Event Handling

Confirming reported behavior with Mozilla trunk binary 2002061707 on WinNT.
IE6 and Mozilla behave differently on the testcase -

Comment 3

[Pham]

.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Andrea Polci]

The bug is still present with firefox 1.5.0.4

Comment 6

[Antonio Petrelli]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 8

[Martijn Wargers (dead)]

Attachment: 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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Er.... shouldn't there be two alerts no matter what?

Comment 10

[Martijn Wargers (dead)]

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