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.
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
QA Contact: pschwartau → rakeshmishra
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?
The bug is still present with firefox 184.108.40.206
(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.
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.
You need to log in before you can comment on or make changes to this bug.