50092 - onfocus event in Textarea tag partially fails.

Status: VERIFIED DUPLICATE of bug 49986

(Core :: Layout, defect, P3)

Description

[Nasiruddin M.S]

onfocussing the textarea, the alert message is displayed 4 times rather than
once.

Comment 1

[Kevin McCluskey (gone)]

Dividing up claytons bugs to triage.

Comment 2

[waqar]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 3

[gerardok]

massive update for QA contact.

Comment 4

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I only see one copy of the alert on linux build 2001-02-12-08.  Is this still a
problem on Solaris?

Comment 6

[bsharma]

qa contact updated.

Comment 7

[Shirley Liu]

Tested Mozilla build 2001040604 on PC Win2000, only one copy of alert message
displayed.

Tested Netscape6.01A on Solaris Sparc 2.8, xpinstall 03-26-2001, nroot, full
package, non-default location, the alert message kept displaying by clicking
"OK" each time.  

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 9

[Kevin McCluskey (gone)]

bulk reassigning Waqar's bugs to Don.

Comment 10

[Jay Yan]

We are working on this bug now, together with bug 49986 and 50047 at the same
time, I believe these 3 bugs are similar.

Comment 11

[Jay Yan]

Attachment: patch for bug 50092, bug 50047, bug 49986, bug 122311

In fact, the Alert window popups without stop(instead of popuping 4 times
only), 
The popup of first time is normal, it starts up the event loop from GDK event
to gtkHandleEvent, then EventStateManager->PostHandleEvent, then
HandleDomEvent, then the js fire up the popup, if user clicks OK to destroy the
alert window, browser window get a NS_ACTIVATE event in PreHandleevent(),
browser window search its focuselement and focusdocument, and tell the textarea
to handle it's dom event again, so a new popup window popups again, then the
loop continues without end. I made a patch, it added two functions in
nsIEventStateManager.h and nsEventStateManager.h, they set and get the flag
whether current EventStatemanager is on activating. When the browser window get
NS_ACTIVATE in PreHandleEvent, it sets the EventStateManager of textarea to
TRUE, sendFocusBlur will not fire HandleDomEvent while this flag is true.

This patch includes the fix for bug 122311, and this patch can also fix bug
49986 and bug 50047

Please see the function stack while abnormal is occurring:

main(argc = 1, argv = 0xffbfeedc)
main1(argc = 1, argv = 0xffbfeedc, nativeApp = (nil))
nsAppShellService::Run(this = 0x832c8)
nsAppShell::Run(this = 0x91790)
gtk_main(0x135dc0, 0x226748, 0x0, 0x0, 0x0, 0x0)
g_main_run(0x219dd8, 0x219dd8, 0x1, 0x0, 0x0, 0x0)
g_main_iterate(0x1, 0x1, 0x19, 0xfdea4648, 0xfea0d1b4, 0x5)
g_main_dispatch(0xffbfea08, 0xa24d8, 0x1, 0x0, 0xfe8965b4, 0x2)
gdk_event_dispatch(0x0, 0xffbfea08, 0x0, 0x3, 0xfee31b84, 0xffbfe970)
handle_gdk_event(event = 0x22b488, data = (nil))
gtk_main_do_event(0x22b488, 0x0, 0xfe4b07d0, 0xfe63a000, 0x0, 0x0)
gtk_widget_event(0xe8f88, 0x22b488, 0xfffffffc, 0xf, 0x9, 0xf00031)
gtk_signal_emit(0xe8f88, 0x1f, 0x22b488, 0xffbfe6a0, 0x0, 0x0)
gtk_signal_real_emit(0xe8f88, 0x1f, 0xffbfe320, 0x0, 0x0, 0xffbfe338)
gtk_marshal_BOOL__POINTER(0xe8f88, 0xfecaef98, 0x0, 0xffbfe320, 0x0,
0xffbfe2f0)
gtk_window_focus_in_event(0xe8f88, 0x22b488, 0x0, 0x0, 0xfe8965b4, 0x2)
gtk_widget_event(0xe8ff0, 0xffbfe17c, 0x0, 0x3, 0xfee31b84, 0xc54a0)
gtk_signal_emit(0xe8ff0, 0x1f, 0xffbfe17c, 0xffbfe108, 0x0, 0x0)
gtk_signal_real_emit(0xe8ff0, 0x1f, 0xffbfdd88, 0x0, 0x0, 0xffbfdda0)
gtk_handlers_run(0xc2550, 0xffbfdcf4, 0xe8ff0, 0xffbfdd88, 0x0,0xf00031)
gtk_marshal_BOOL__POINTER(0xe8ff0, 0xfdef00c0, 0x19a088, 0xffbfdd88,0x0, 0x0)
handle_mozarea_focus_in(aWidget = 0xe8ff0, aGdkFocusEvent = 0xffbfe17c,aData =
0x19a088)
nsWindow::HandleMozAreaFocusIn(this = 0x19a088)
nsWindow::DispatchSetFocusEvent(this = 0x19a088)
nsWidget::DispatchFocus(this = 0x19a088, aEvent = STRUCT)
nsWidget::DispatchWindowEvent(this = 0x19a088, event = 0xffbfda74)
nsWidget::DispatchEvent(this = 0x19a088, aEvent = 0xffbfda74, aStatus =
nsEventStatus_eIgnore)
nsWebShellWindow::HandleEvent(aEvent = 0xffbfda74)
GlobalWindowImpl::Focus(0xdbd18, 0x1, 0xfe033fba, 0xffffffff, 0x0,0xb6848)
nsWindow::SetFocus(this = 0x2616e0, aRaise = 1)
nsWindow::DispatchSetFocusEvent(this = 0x2616e0)
nsWindow::DispatchActivateEvent(this = 0x2616e0)
nsWidget::DispatchFocus(this = 0x2616e0, aEvent = STRUCT)
nsWidget::DispatchWindowEvent(this = 0x2616e0, event = 0xffbfd3dc)
nsWidget::DispatchEvent(this = 0x2616e0, aEvent = 0xffbfd3dc, aStatus =
nsEventStatus_eIgnore)
HandleEvent(aEvent = 0xffbfd3dc)
nsViewManager::DispatchEvent(this = 0x2615d8, aEvent = 0xffbfd3dc,aStatus =
0xffbfd1c0)
nsView::HandleEvent(this = 0x22e158, event = 0xffbfd3dc, aEventFlags = 0,
aStatus = 0xffbfd1c0, aForceHandle = 1, aHandled = 1)
PresShell::HandleEvent(0x261aa8, 0x22e158, 0xffbfd3dc, 0xffbfd1c0,
0x1,0xffbfd0d8)
PresShell::HandleEventInternal(0x261aa8, 0xffbfd3dc, 0x22e158, 0x1,0xffbfd1c0,
0xff00)
nsEventStateManager::PreHandleEvent(0x3e47b0, 0x22dea8, 0xffbfd3dc,0x48ef8c,
0xffbfd1c0, 0x22e158)
nsHTMLTextAreaElement::SetFocus(0x72e250, 0x755b88, 0xffbfcc00, 0x2,0xffbfce94,
0xffbfd351)
nsEventStateManager::SetContentState(0x6ff1f0, 0x72e250, 0x2,0xffbfc84c,
0xffbfce94, 0x98ec8)
nsEventStateManager::SendFocusBlur(0x6ff1f0, 0x755b88, 0x72e250, 0x0,0x1, 0x0)
nsHTMLTextAreaElement::HandleDOMEvent(0x72e250, 0x755b88, 0xffbfc218,0x0, 0x1,
0xffbfc240)
nsGenericElement::HandleDOMEvent(0xfc1d9468, 0x755b88, 0xffbfc218, 0x0,0x1,
0xffbfc240)
nsEventListenerManager::HandleEvent(0x72e318, 0x755b88, 0xffbfc218,0xffbfbf10,
0x9151c8, 0x1)
nsEventListenerManager::HandleEventSubType(0x72e318, 0x737138,0x8ee838,
0x9151c8, 0x1, 0x7)
nsJSEventListener::HandleEvent(0xfceca1e8, 0x8ee838, 0x0, 0x0, 0x1,0x0)
nsJSContext::CallEventHandler(0x5b91a0, 0x93d4d0, 0x3adeb0, 0x1,0xffbfb214,
0xffbfb0a4)
JS_CallFunctionValue(cx = 0x5b1048, obj = 0x93d4d0, fval = 3858096,argc = 1U,
argv = 0xffbfb214, rval = 0xffbfad14)
js_InternalInvoke(cx = 0x5b1048, obj = 0x93d4d0, fval = 3858096, flags = 0,
argc = 1U, argv = 0xffbfb214, rval = 0xffbfad14)
js_Invoke(cx = 0x5b1048, argc = 1U, flags = 2U)
js_Interpret(cx = 0x5b1048, result = 0xffbfaad8)
js_Invoke(cx = 0x5b1048, argc = 1U, flags = 0)
XPC_WN_CallMethod(cx = 0x5b1048, obj = 0x3634d8, argc = 1U, argv = 0x8ee8c8, vp
= 0xffbfa684)
XPCWrappedNative::CallMethod(ccx = CLASS, mode = CALL_METHOD)
XPTC_InvokeByIndex(0x5b90bc, 0x3e, 0x1, 0xffbfa3b8, 0x1, 0xffbfa2f4)
GlobalWindowImpl::Alert(0x5b90b8, 0x8d4158, 0xffbfa3b8, 0x0,
0xff064168, 0x0)
nsPrompt::Alert(this = 0x169c78, dialogTitle = (nil), text = 0xffbf9ecc)
nsPromptService::Alert(this = 0x16f2f0, parent = 0xdbd1c, dialogTitle =
0x6ffca0, text = 0xffbf9ecc)

Comment 12

[Jay Yan]

Attachment: viewable patch for bug 50092, bug 50047, bug 49986, bug 122311

I checked auto-detect to determine the content type, but why bugzilla regard it
as a binary file, I reattach it as plain text format.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 67717 [details] [diff] [review]
viewable patch for bug 50092, bug 50047, bug 49986, bug 122311

That's what the "patch" checkbox is for.. :)

Comment 14

[Boris Zbarsky [:bzbarsky]]

bryner?  joki?  Could you review the patch?

Comment 15

[Jay Yan]

Hi Bryner, 
I tested this patch for bug 120209, it does not work for it. but it seems 
something similiar. perhaps I can do something for bug 120209.
JayYan

Comment 16

[Brian Ryner (not reading)]

I don't think this is necessarily the correct fix.  It may be desirable to fire
onfocus handler when an activate is received -- testing with IE, it fires the
onfocus handler again if you deactivate and reactivate the window, in
practically every case except for this one where onfocus displays a dialog.

Comment 17

[Jay Yan]

yes, bryner, you are right. it breaks some feature, look for better way. 
--Jay

Comment 18

[Sergi]

*** This bug has been marked as a duplicate of 49986 ***

Comment 19

[Moied]

Verified dup of 49986