onfocus event in Textarea tag partially fails.




19 years ago
17 years ago


(Reporter: nasiruddin.shaikh, Assigned: dcone)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: suntrak-n6, URL)


(1 attachment, 1 obsolete attachment)



19 years ago
onfocussing the textarea, the alert message is displayed 4 times rather than
Dividing up claytons bugs to triage.
Assignee: clayton → waqar

Comment 2

19 years ago
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.
Target Milestone: --- → Future

Comment 3

19 years ago
massive update for QA contact.
QA Contact: petersen → lorca


18 years ago
Whiteboard: suntrak-n6
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
I only see one copy of the alert on linux build 2001-02-12-08.  Is this still a
problem on Solaris?

Comment 6

18 years ago
qa contact updated.
QA Contact: gerardok → bsharma

Comment 7

18 years ago
Tested Mozilla build 2001040604 on PC Win2000, only one copy of alert message

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.  
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout


18 years ago
QA Contact: bsharma → moied
bulk reassigning Waqar's bugs to Don.
Assignee: waqar → dcone

Comment 10

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


17 years ago
Depends on: 122311

Comment 11

17 years ago
Created attachment 67715 [details]
patch for bug 50092, bug 50047, bug 49986, bug 122311

In fact, the Alert window popups without stop(instead of popuping 4 times
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,
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 =
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 =
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 =
HandleEvent(aEvent = 0xffbfd3dc)
nsViewManager::DispatchEvent(this = 0x2615d8, aEvent = 0xffbfd3dc,aStatus =
nsView::HandleEvent(this = 0x22e158, event = 0xffbfd3dc, aEventFlags = 0,
aStatus = 0xffbfd1c0, aForceHandle = 1, aHandled = 1)
PresShell::HandleEvent(0x261aa8, 0x22e158, 0xffbfd3dc, 0xffbfd1c0,
PresShell::HandleEventInternal(0x261aa8, 0xffbfd3dc, 0x22e158, 0x1,0xffbfd1c0,
nsEventStateManager::PreHandleEvent(0x3e47b0, 0x22dea8, 0xffbfd3dc,0x48ef8c,
0xffbfd1c0, 0x22e158)
nsHTMLTextAreaElement::SetFocus(0x72e250, 0x755b88, 0xffbfcc00, 0x2,0xffbfce94,
nsEventStateManager::SetContentState(0x6ff1f0, 0x72e250, 0x2,0xffbfc84c,
0xffbfce94, 0x98ec8)
nsEventStateManager::SendFocusBlur(0x6ff1f0, 0x755b88, 0x72e250, 0x0,0x1, 0x0)
nsHTMLTextAreaElement::HandleDOMEvent(0x72e250, 0x755b88, 0xffbfc218,0x0, 0x1,
nsGenericElement::HandleDOMEvent(0xfc1d9468, 0x755b88, 0xffbfc218, 0x0,0x1,
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,
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

17 years ago
Created attachment 67717 [details] [diff] [review]
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.
Attachment #67715 - Attachment is obsolete: true
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.. :)
Attachment #67717 - Attachment is patch: true
bryner?  joki?  Could you review the patch?
Keywords: mozilla0.9.9, patch, review

Comment 15

17 years ago
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.
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

17 years ago
yes, bryner, you are right. it breaks some feature, look for better way. 

Comment 18

17 years ago

*** This bug has been marked as a duplicate of 49986 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 19

17 years ago
Verified dup of 49986 
You need to log in before you can comment on or make changes to this bug.