This bug report originated from issue QTBUG-2322 <http://bugreports.qt.nokia.com/browse/QTBUG-2322> --- Description --- In the following snippet of HTML the onClicked/onChange handlers are called differently when entering text and then clicking on the button. <html> <body> <script> function onChange() { alert(document.f1.t1.value); } function onClick() { alert('onClick'); } </script> <FORM name="f1"> <INPUT type=text name="t1" onChange="onChange()"> </INPUT> <INPUT type=button name="b1" value=button onClick="onClick()"> </INPUT> </FORM> </body> </html>
Created attachment 44232 [details] Test case in an HTML file In the test case provided above (copied from the bug description), the text fields onchange event fires properly no matter where you click (on the button or not) but if you click on the button and the onchange event for the text field fires, then the onclick event for the button does not. You actually have to click again on the button to get the onclick event (in which case the text wasn't changed so the onchange event does not fire). It doesn't matter if the onchange handler returns true or not. Tested on Chrome 4 and Chromium 4.0.262.0 .
I have a similar problem where if the button is pressed, then only the button's onclick handler is called and not the onchange handler. When I tried to create a minimal test case for this bug, the behavior changed to this one, so I think there is a race condition here where one event handler precludes the other from firing.
Also, another interesting thing (sorry for the bug spam, but I just tested something else), is that onmousedown does not suffer from this problem - if you use onmousedown instead of onclick then both events fire normally.
(In reply to comment #3) > Also, another interesting thing (sorry for the bug spam, but I just tested > something else), is that onmousedown does not suffer from this problem - if you > use onmousedown instead of onclick then both events fire normally. I can't recreate this problem at all in QtLauncher. Have you tried it there? This is what I did, in the order I did it - maybe I'm misunderstanding the bug but it looks good to me: Do: edit text field, click button Result: Get Onclick and Onchange popup in that order. Do: leave text alone, click button. Result: get onclick popup only Do: edit text again, click elsewhere on screen Result: get onchange popup only Do: leave text alone, click button. Result: get onclick popup only Do: edit text field again, click button Result: Get Onclick and Onchange popup in that order.
Confirmed in QtLauncher with trunk. Both Chrome and Firefox has this behavior, but Safari does not: 1. Click the text field. 2. Enter text 3. Click the button Safari gives you an alert for each of the two even handlers, onChange() and onClick(), but QtLauncher and Chrome does not
(In reply to comment #5) > Confirmed in QtLauncher with trunk. Both Chrome and Firefox has this behavior, > but Safari does not: > > 1. Click the text field. > 2. Enter text > 3. Click the button > > Safari gives you an alert for each of the two even handlers, onChange() and > onClick(), but QtLauncher and Chrome does not Weird, I still can't reproduce this on QtLauncher (Kubuntu Karmic) in trunk. I click on the input field, enter text, click the button and get two pop ups one for the OnClick and one displaying the text I entered.
Reproduced on Snow Leopard with Qt 4.7 trunk (HEAD 03f8f1df0d88f5ffe0b3120cffce614cbeefdb70) and WebKit trunk (r59155). (In reply to comment #5) > Safari gives you an alert for each of the two even handlers, onChange() and onClick(), but QtLauncher and Chrome does not So we have different behaviors on different WebKit browsers. I was wondering if this is really a bug or not.
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.