Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.8+) Gecko/20020205 Please take look to the attached testcase. Steps to reproduce: 1. Give the text area 'Description:' focus by clicking in the text area. 2. Type some garbage into 'Description:' textarea. 3) Tab out, giving 'Committed:' button the focus. 4) Click 'OK' to the message box prompt. Actual results are: When you close this alert window then note that the lines like "WEBSHELL+ = nn" repeatedly appears in the console. When the number for the webshells amounts to the some limit (for my case it is approximately 250) then mozilla crashes by the Segmentation Fault.

wfm with testcase and win2k build 20020207..

As I see it is Solaris specific problem.

WFM 2002020703/WinNT4

This turned out to be another blocker for Siebel to release their application. The crash (just follow the test case) consistantly happened at: @1 (l@7) signal SEGV (no mapping at the fault address) in nsEventStateManager::PreHandleEvent at line 414 in file "nsEventStateManager.cpp" The function/method is nsEventStateManager::PreHandleEvent(),and line 414 code is: ... gLastFocusedContent->GetDocument(*getter_AddRefs(doc)); The crash call stack is: nsWidget::DispatchEvent(this = 0x21bbd0, aEvent = 0xffbed3ec, aStatus = nsEventStatus_eIgnore) nsWebShellWindow::HandleEvent(aEvent = 0xffbed3ec) GlobalWindowImpl::Focus(this = 0x211bf0) nsWindow::SetFocus(this = 0x252d48, aRaise = 1) nsWindow::DispatchSetFocusEvent(this = 0x252d48) nsWidget::DispatchFocus(this = 0x252d48, aEvent = STRUCT) nsWidget::DispatchWindowEvent(this = 0x252d48, event = 0xffbecedc) nsWidget::DispatchEvent(this = 0x252d48, aEvent = 0xffbecedc, aStatus = nsEventStatus_eIgnore) HandleEvent(aEvent = 0xffbecedc) nsViewManager::DispatchEvent(this = 0x2510a0, aEvent = 0xffbecedc, aStatus = 0xffbeccc8) nsView::HandleEvent(this = 0x252ce0, event = 0xffbecedc, aEventFlags = 28U, aStatus = 0xffbeccc8, aForceHandle = 1, aHandled = 1) PresShell::HandleEvent(this = 0x250528, aView = 0x252ce0, aEvent = 0xffbecedc, aEventStatus = 0xffbeccc8, aForceHandle = 1, aHandled = 1) PresShell::HandleEventInternal(this = 0x250528, aEvent = 0xffbecedc, aView = 0x252ce0, aFlags = 1U, aStatus = 0xffbeccc8) nsEventStateManager::PreHandleEvent(this = 0x45cc08, aPresContext = 0x24e5d8, aEvent = 0xffbecedc, aTargetFrame = 0x5770e8, aStatus = 0xffbeccc8, aView = 0x252ce0)

considered a blocker for ns6 support by Siebel

Major corporations depend on eapp bugs, and need them to be fixed before they can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword and making sure the bugs get re-evaluated if they are targeted beyond 1.0.

I run into this too.

This is all platform ccing danm

eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to nominate. This is an important issue and deserves to be nsbeta1+ by the ADT. This issue blocks support of Siebel's appliaction by Sun's branded NS6.2

cc bryner

The crash was also reproduced on Linux with mozilla094, and the call stack is the same: Program received signal SIGSEGV, Segmentation fault. 0x410048bc in nsEventStateManager::PreHandleEvent (this=0x841edd8, aPresContext=0x82c04e0, aEvent=0xbfffeb20, aTargetFrame=0x8505ae0, aStatus=0xbfffea4c, aView=0x82aeb08) at nsEventStateManager.cpp:413 413 gLastFocusedContent->GetDocument(*getter_AddRefs(doc)); (gdb) where #0 0x410048bc in nsEventStateManager::PreHandleEvent (this=0x841edd8, aPresContext=0x82c04e0, aEvent=0xbfffeb20, aTargetFrame=0x8505ae0, aStatus=0xbfffea4c, aView=0x82aeb08) at nsEventStateManager.cpp:413 #1 0x41ba83af in ?? () #2 0x41ba7fa8 in ?? () #3 0x41e1b145 in ?? () #4 0x41e2794f in ?? () #5 0x41e1a734 in ?? () #6 0x40cc3df8 in nsWidget::DispatchEvent (this=0x82c0ab8, aEvent=0xbfffeb20, aStatus=@0xbfffeae8) at nsWidget.cpp:1387 #7 0x40cc3a3c in nsWidget::DispatchWindowEvent (this=0x82c0ab8, event=0xbfffeb20) at nsWidget.cpp:1278 #8 0x40cc3ae4 in nsWidget::DispatchFocus (this=0x82c0ab8, aEvent=@0xbfffeb20) at nsWidget.cpp:1300 #9 0x40ccabbe in nsWindow::DispatchSetFocusEvent (this=0x82c0ab8) at nsWindow.cpp:1311 #10 0x40ccaaee in nsWindow::SetFocus (this=0x82c0ab8, aRaise=1) at nsWindow.cpp:1266

This is probably a gtk focus bug. I'll take it.

I'm not able to reproduce this on build 2002021412, on Linux. I see the onblur fire, then the onchange fire, and that's all.

marking nsbeta1+, possibly only on Solaris, or more common there?

Another testcase, change the onchange event to onmouseout event. To reproduce the problem: Load the testcase, click the textarea, then move the pointer out of the textarea. The onblur keeps fire, then segment fault. Can you reproduce it on Linux, bryner?

No, I'm still not seeing this bug.

bryner: this problem is specific to the 0.9.4 branch, and it's very critical that we get a fix for this on the 0.9.4 branch. can you investigate? it appears to be GTK specific as you mentioned.

Repro Steps: 1) Give the textbox 'Description:' focus by clicking in the text area. Make sure to leave the mouse cursor within the text area. 2) Type some garbage into 'Description:' 3) Tab out, giving 'Committed:' checkbox the focus. 4) Hit Enter at message box prompts. Result: Several message boxes are displayed informing the user which events have fired. After a few prompts, the browser terminates. Expected: Message boxes are displayed. After user hits Enter at message box prompts, normal functionality returns AND 'Committed' check box has focus. Hitting the Space Bar checks/unchecks 'Committed' check box.

Good news - this is fixed by the patch on bug 120209. When that is checked into the trunk, we can also check in the fix on the branch. Which branch(es), exactly, does it need to go on?

Brian, Thanks for locating the fix. I am going to apply the patch of 120209 in Siebel tomorrow. If it works there too, it will be checked into Sun's Netscape6.2.1 branch by Sun.

That fix not fixes another testcase: <html> <head><title>Too many webshells</title></head> <body> <form> <textarea name='s_1_1_42_0' onblur='alert("TextArea lose focus");'> </textarea> </form> </body> </html> Give focus to textarea and then move mouse pointer out of mozilla window. Alert window will pop up. Dismiss it and next alert will pop up etc.... May be this issue have different cause, I'm not sure. I think that we shouldn't fire dom events (namely, onblur and onfocus), when the whole app loses focus. (Tested on Solaris 2.8 with patch from 120209 applied).

I was able to fix this by the same way as in bug 120209, but for NS_DEACTIVATE event (checking if suppress focus is already TRUE) Brian, does it sounds reasonable for you?

Why is this nominated for 094? What is driving? A bugscape bug?

How close are we to a fix for this one. Adding Buckland.

we appear to be pretty close... the fix for bug 120209 is definitely needed. there may be another patch required as well.

We have to fire onblur when the window is deactivated and onfocus when the window gets activated. This is a fundamental requirement of the DOM events.

except for dependent windows like alerts (just documenting our converation in bug)

The patch works -- almost. The browser no longer crashes. But using the 'Orginial Siebel Repro Case' attached test case, when the checkbox 'Committed' changes from checked or unchecked the OnChange() event is fired. It should only fire once the control loses focus.

Bill, does that last problem only happen on unix? If not, it's probably completely unrelated and should be filed as a separate bug.

Is this related to or the same as: http://bugzilla.mozilla.org/show_bug.cgi?id=101834?

Further playing around with patched build resulted in: ###!!! ASSERTION: Attempt to decrement focus controller's suppression when no suppression active! : 'PR_FALSE', file nsFocusController.cpp, line 416 ###!!! Break: at file nsFocusController.cpp, line 416

Brian - Tried repro case on Win2K NS 6.2.1 w/ JRE 1.4 and experienced the same behavior. So the patch does work! :-) Sorry for the confusion and thanks for everyone's help.

Brian - Tried repro case on Win2K NS 6.2.1 w/ JRE 1.4 and experienced the same behavior. So the patch does work! :-) Sorry for the confusion and thanks for everyone's help.

Does this repro on 094?

yes, but only under one of the XP_UNIX builds.

Removing KW: edt0.9.4

Can we close out this bug then? Any objections?

Wait a minute! What about scenario from comment #22? It's still not fixed and you can't get rid of those alert windows. Also, could point me where DOM Events spec says that we must fire onfocus when upon activation and onblur upon deactivation? I can't find it in the doc.

Marking this as duplicate of 120209, since the fix of 120209 dose fix the problem in Siebel, for whom this bug was filed. *** This bug has been marked as a duplicate of 120209 ***

In Siebel's QA test, this crash still happened, and after some investigation, we found out that the fix in 120209 only fix part of the problem. Reopen the bug.

Attaching a work around to prevent crashing for now.

Re-attach the same work around, but taking out the debug print.

Marking it opembed-, embed

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!

Comment on attachment 75605 [details] [diff] [review] same work around without debug print please fix the indenting to be consistent here (looks like maybe you used tabs instead of spaces), and remove the unneeded braces. With those changes, r=bryner.

reassinging to joe chou, since he has a fix.

Actually that was a work around from Andrew Brygin. Re-assign to Andrew. Also the remaining issue (some extra event got generated) is not that critical, changing to p3.

yet, Andrew, I think you should check in your patch to mozilla 1.0, since the patch does prevent the browser from crashing. At the least, it is a defensive change, and the risk of breakage is none.

removing myself from cc:

what is the situation with this bug? I could not crash with the testcases in 1.0.1/win2k/20020815 or 1.1b/win2k/20020815

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

WFM Mozilla 1.3

The code in the proposed patch was added in 1.440 of nsEventStateManager.cpp: revision 1.440 date: 2003/05/12 07:11:11; author: bryner%netscape.com; state: Exp; lines: +229 -185 Fixes for a number of focus problems: Bug 201996 (caret blinking in field, but can't type) Bug 200735 (window is raised when opening link in a new tab) Bug 203117 (unable to scroll view source window with keyboard) Bug 194104 (focus is in last tab when opening new window with tabgroup) See bug 201996 comment 18 -> WORKSFORME