On macOS 9.1 and macOS 10 --- build ID: 2001-09-26-04-0.9.4 The onBlur Javascript event is not getting triggered when I click on the <input type=submit> form control see the attached test case.

on RedHat Linux 7.1 -- build ID : 2001-09-26-04-0.9.4 When I hit the "Submit" button - the onBlur event is called upon 2-3 times and then eventually results in a crash. Here is the stack trace:- ============================= Incident ID 35925557 Stack Signature: nsEventStateManager::PreHandleEvent() 28642eb5 Bug ID Trigger Time : 2001-09-26 15:23:38 Email Address: madhur@netscape.com User Comments Build ID: 2001092605 Product ID: Netscape6.20 Platform ID: LinuxIntel Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Stack Trace nsEventStateManager::PreHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchFocus() nsWindow::DispatchSetFocusEvent() nsWindow::SetFocus() GlobalWindowImpl::Focus() nsWebShellWindow::HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchFocus() nsWindow::DispatchSetFocusEvent() nsWindow::HandleMozAreaFocusIn() handle_mozarea_focus_in() libgtk-1.2.so.0 + 0x95fbc (0x40278fbc) libgtk-1.2.so.0 + 0xc9916 (0x402ac916) libgtk-1.2.so.0 + 0xc8c3d (0x402abc3d) libgtk-1.2.so.0 + 0xc69f5 (0x402a99f5) libgtk-1.2.so.0 + 0x1010e9 (0x402e40e9) libgtk-1.2.so.0 + 0x109dac (0x402ecdac) libgtk-1.2.so.0 + 0x95fbc (0x40278fbc) libgtk-1.2.so.0 + 0xc8c7d (0x402abc7d) libgtk-1.2.so.0 + 0xc69f5 (0x402a99f5) libgtk-1.2.so.0 + 0x1010e9 (0x402e40e9) libgtk-1.2.so.0 + 0x94fe4 (0x40277fe4) handle_gdk_event() libgdk-1.2.so.0 + 0x17e4f (0x4032fe4f) libglib-1.2.so.0 + 0x117f3 (0x403627f3) libglib-1.2.so.0 + 0x11dd9 (0x40362dd9) libglib-1.2.so.0 + 0x11ebe (0x40362ebe) nsAppShell::DispatchNativeEvent() nsXULWindow::ShowModal() nsWebShellWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJS() nsWindowWatcher::OpenWindow() nsPromptService::DoDialog() nsPromptService::Alert() nsPrompt::Alert() GlobalWindowImpl::Alert() XPTC_InvokeByIndex() XPCWrappedNative::CallMethod() XPC_WN_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsGenericElement::HandleDOMEvent() nsHTMLInputElement::HandleDOMEvent() nsEventStateManager::PreHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchFocus() nsWindow::DispatchDeactivateEvent() nsWindow::HandleMozAreaFocusOut() handle_mozarea_focus_out() libgtk-1.2.so.0 + 0x95fbc (0x40278fbc) libgtk-1.2.so.0 + 0xc9916 (0x402ac916) libgtk-1.2.so.0 + 0xc8c3d (0x402abc3d) libgtk-1.2.so.0 + 0xc69f5 (0x402a99f5) libgtk-1.2.so.0 + 0x1010e9 (0x402e40e9) libgtk-1.2.so.0 + 0x109ed4 (0x402eced4) libgtk-1.2.so.0 + 0x95fbc (0x40278fbc) libgtk-1.2.so.0 + 0xc8c7d (0x402abc7d) libgtk-1.2.so.0 + 0xc69f5 (0x402a99f5) libgtk-1.2.so.0 + 0x1010e9 (0x402e40e9) libgtk-1.2.so.0 + 0x94fe4 (0x40277fe4) handle_gdk_event() libgdk-1.2.so.0 + 0x17e4f (0x4032fe4f) libglib-1.2.so.0 + 0x117f3 (0x403627f3) libglib-1.2.so.0 + 0x11dd9 (0x40362dd9) libglib-1.2.so.0 + 0x11ebe (0x40362ebe) nsAppShell::DispatchNativeEvent() nsXULWindow::ShowModal() nsWebShellWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJS() nsWindowWatcher::OpenWindow() nsPromptService::DoDialog() nsPromptService::ConfirmEx() nsPrompt::ConfirmEx() nsNSSDialogs::ConfirmDialog() nsNSSDialogs::ConfirmPostToInsecure()

No crash on the testcase in today's linux trunk (2001092608). branch only?

Also, the onblur="" event does get triggered, but onblur is for the focus leaving it. Click on it but do not release the mouse and drag the mouse off of the submit so that you do not actually submit the form. Then click in the body, and you will see that the onblur="alert()" pops up. That is the correct behaviour. If this is not happening though on the branch, it's correct that it's a bug

I have checked this on the Linux branch build for today and I get a crash each time. And yes, you are right -- the onBlur event gets triggered when I click on the submit button. This should not be the case. The onBlur event is supposed to be activated when you take the focus off the submit button by clicking somplace else on the window or tabbing away. see http://www.w3.org/TR/html401/interact/scripts.html#adef-onblur User should not have to click and hold the mouse and drag the mouse off the submit button - for the onBlur event to occur and to submit the form. According to w3c, just a click is required for form submission. ** I disagree that this is the accurate behaviour. ** The crash happens on Linux branch build for today - build ID mentioned in my first comment. On MacOS 9.1 and 10 , the onBlur event does not work at all. On win2000, the onBlur event is triggered when the formcontrol receives the focus (same as on Linux except for the crash --- this is not right). No crash occurs here. Tested on branch build for all the platforms.

I think that my statements got a bit confused. If I click and release on the submit button: the submit gets sent, onblur does NOT get launched. If I click and move off the submit button so that the submit gets focus yet don't submit the form, and if I click anywhere else, the onfocus handler gets called and the alert pops up. The behaviours I'm seeing is correct AFAIK. No crash and the onblur seems to working fine... Should the onblur handler be called for clicking on it? I don't think so... I could be wrong though.

nominating for nsbranch

got a crash again on Linux 7.1 Build ID: 2001-09-27-04-0.9.4 (branch) incident ID # 35972749

what are the chances of this making the 0.9.4 branch?

doesn't crash on Mac OS trunk, but it doesn't bring up the onblur dialog either. I suspect we don't bring it up the dialog because it is happening during the teardown of a page. Odd case, something we probably won't see in the wild, but worth looking at on the platforms that crash.

Using the test caseon a Win 98 system, I was able to reproduce the crash on yesterday's Branch Build.

on linux 7.1 :- (branch build id -- 2001-10-11-02-0.9.4) =============== 1. When I **tab away from** the submit button, the onblur event is triggered. When I do 'ok' - it does not result in a crash --- *Expected behaviour* 2. When I click **on** the submit button - the onblur event is triggered (firstly, the event should not be triggered when the button has the focus, via mouse click). When I click 'ok' on the alert popup - the event is triggered 2-3 times and eventually results in a crash. This plaform gets the crash. on macOS 9.1 :- =============== 1. When I **tab away from** the submit button, the onblur event is triggered. When I do a mouse click 'OK' or a keyboard enter 'OK' - it does not result in a crash --- *Expected behaviour* 2. when i click on the submit button - there is a form submission --- *this is also the expected behaviour* no crash seen on this platform on win2000 & macOS 10:- (branch build for 2001-10-11) ============= 1. When I **tab away from** the submit button, the onblur event is triggered. When I do a mouse click 'OK' or a keyboard enter 'OK' - it does not result in a crash --- *Expected behaviour* 2. when i click on the submit button, the onblur event is triggered and agfter I click 'OK' on the alert popup , there is a form submission. *not the expected behaviour* -- the onblur event should not be triggered when I click on the submit button. No crash seen on these platforms.

let's see if this a crasher in recent talkback data. can you help jay?

Adding M094 & N620 [@ nsEventStateManager::PreHandleEvent] to summary for tracking. There have only been a couple of crashes on the current branch reported. Here is the source file and a couple of comments: Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/events/src/nsEventStateManager.cpp line : 414 (36583241) Comments: Crash when using the testcase in Bugzilla ... (36532964) Comments: running a testcase for Javascript event - onblur for <input type="submit"> There are quite a few crashes with Mozilla 0.9.4, but that crash is already reported in bug 93471, which might even be a dup of this bug. Take a look there and see if they are the same crash or similar.

Can we get QA to do a little testing on this? Let's work a little of gerardo's magic tool.

How often does this happen on the different platforms?

1) When I run the 1st attached testcase (here an alert box is called upon when the onblur event is triggered), I get a crash each time on linux 7.1 see my Additional Comments on 2001-10-12 11:29 2) I ran a testcase for the <input type=submit> onblur event - which when triggered should change the value of an input textbox. Here I did not call the alert box. (i am attaching another testcase which does not result in a crash - but still dispalys how the onblur event is not behaving as desired) Result:- ======== --------------on macOS 9.1------------- 1. When I **tab away from** the submit button, the onblur event is triggered. --- *Expected behaviour* 2. when i click on the submit button - there is a form submission --- *this is also the expected behaviour* no crash seen on this platform --------------on linux 7.1 & win2000------------- 1. When I **tab away from** the submit button, the onblur event is triggered. That is the value of the input textbox is changed --- *Expected behaviour* 2. when i click on the submit button, the onblur event is triggered, that is - the value of the input text box is changed at this time. *not the expected behaviour* -- the onblur event should not be triggered when I click on the submit button. No crash seen on these platforms.

I notice that the crash problem on Linux 7.1 only occurs when a new window environment is created (alert box) when the onblur event is triggered. The main things to consider in this bug :- 1. why does the new window environment (such as alert box, prompt box, etc.) result in a crash bug (on Linux 7.1 only) 2. On certain platforms (win2000 amd Linux 7.1) - the onblur event is trigerred when the control has the focus. This is not the desired behaviour of the event for a control. see http://www.w3.org/TR/html401/interact/scripts.html#adef-onblur

Adding PDT to keep on the radar for review.

Gerardo and Madhur - are there any top sites which use these elements in this fashion? Can you use the tool to find out and post results here?

PDT-, because we are not seeing this reproduced widely in the wild.

Too late for 0.9.6, this needs retargeting.

0.9.6 has passed, moving to 0.9.7. Load balancing 0.9.7 list shortly

getting the crash on linux 7.1 in 2001-11-276-17-6.2.1 build incident ID # 38581741

Moving bugs from 0.9.7 for triaging in 0.9.8

removing old PDT grafitti, and nominating as nsbeta1. this one seems to continually be pushed out, but os a bad bug. what are the chances this will be fixed by 099? if it can't be addressed, then we should move the target out past 1.0 and nsbeta1-, rather than continually triaging and pushing it out.

nsbeta1- per ADT triage team

moving to mozilla 1.0 (farther tom?)

I am getting the crash on win2k buildID 2002-03-11-09trunk Incident ID : 4055710

i tested this on win2000 build id: 2002-03-18-05trunk . No crash this time. But the onblur event is triggered when the submit button has focus and when the alert box "ok" is clicked/hit enter key, the window loses focus . Tom, i tried this on the experimental build you made. I get a crash there.

getting a crash on platform :- window2000 buildID:- 2002-03-22-05trunk incident ID : 4469956

getting a ctrash on the MFCembed build of 03/27/02, as well. you can download th build from ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-03-27-23-0.9.9ec/embed-win32.zip cc'ing mdunn and chrisd.

Same stack signature is for <INPUT TYPE=IMAGE> (which is same as submit) - see bug 135087. Bigger testcase on: http://www.blooberry.com/test/onblurtest1.htm

*** Bug 135087 has been marked as a duplicate of this bug. ***

WFM 2003032908/trunk/W2K

Please verify

Madhur and I both looked at this with current trunk builds on Windows, Linux, and Mac OSX. Both of Madhur's testcases are now working fine. The onBlur events happen as they are supposed to, the submits happen as they are supposed to, and there is no crash. Resolving WORKSFORME -

With results from Adam, Madhur, and myself, marking Verified.