30785 - crash after repeated blur and focus while waiting for dialog

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:  The test case to be attached launches an alert dialog for the blur
event.  If one causes a blur multiple times (that may not be the exact
condition), I crash.

STEPS TO REPRODUCE:
 * load attached test case
 * quickly do the following:
   + click in textarea
   + click in document
   + click in textarea
   + click in document

ACTUAL RESULTS:
 * crash

EXPECTED RESULTS:
 * no crash

DOES NOT WORK CORRECTLY ON:
 * Linux, mozilla, 2000-03-06-08-M15
 * Linux, mozilla, my debug build, about a week and a half old (I think)

ADDITIONAL INFORMATION:
Stack trace from debug build for segmentation fault:
#0  0x4103fd25 in nsEventStateManager::PreHandleEvent (this=0x8659098, 
    aPresContext=0x8624320, aEvent=0xbfffcba8, aTargetFrame=0x8685984, 
    aStatus=0xbfffcbd0, aView=0x86570f8) at nsEventStateManager.cpp:652
#1  0x410967a7 in PresShell::HandleEvent (this=0x872cb68, aView=0x86570f8, 
    aEvent=0xbfffcba8, aEventStatus=0xbfffcbd0, aHandled=@0xbfffcb08)
    at nsPresShell.cpp:2985
#2  0x4153588d in nsView::HandleEvent (this=0x86570f8, event=0xbfffcba8, 
    aEventFlags=8, aStatus=0xbfffcbd0, aHandled=@0xbfffcb08) at nsView.cpp:798
#3  0x4153581d in nsView::HandleEvent (this=0x8623e08, event=0xbfffcba8, 
    aEventFlags=8, aStatus=0xbfffcbd0, aHandled=@0xbfffcb08) at nsView.cpp:782
#4  0x4153581d in nsView::HandleEvent (this=0x85e8c80, event=0xbfffcba8, 
    aEventFlags=28, aStatus=0xbfffcbd0, aHandled=@0xbfffcb08) at nsView.cpp:782
#5  0x415479d3 in nsViewManager2::DispatchEvent (this=0x865b430, 
    aEvent=0xbfffcba8, aStatus=0xbfffcbd0) at nsViewManager2.cpp:1214
#6  0x40330721 in GlobalWindowImpl::Deactivate (this=0x85e7758)
    at nsGlobalWindow.cpp:2266
#7  0x4064d868 in nsWebShellWindow::HandleEvent (aEvent=0xbfffcddc)
    at nsWebShellWindow.cpp:509
#8  0x407ced46 in nsWidget::DispatchEvent (this=0x8327e30, aEvent=0xbfffcddc, 
    aStatus=@0xbfffcdd8) at nsWidget.cpp:1397
#9  0x407d8c2f in handle_toplevel_focus_out (aWidget=0x8328198, 
    aGdkFocusEvent=0x820899c, aData=0x8327e30) at nsWindow.cpp:2509
#10 0x4089ad69 in gtk_marshal_BOOL__POINTER ()
#11 0x408c8bed in gtk_handlers_run ()
#12 0x408c8032 in gtk_signal_real_emit ()
#13 0x408c6185 in gtk_signal_emit ()
#14 0x408fb75c in gtk_widget_event ()
#15 0x40899fba in gtk_main_do_event ()
#16 0x407c08cb in handle_gdk_event (event=0x820899c, data=0x0)
    at nsGtkEventHandler.cpp:915

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase described in bug

Comment 2

[K Chayka]

Attachment: another similar test case that causes Win98 crash

Comment 3

[K Chayka]

First test case also causes Win98 build 2000030516 crash in XPCOM.DLL. Submitted 
additional test case. It uses mouseover/mouseout and and onclick alert, always 
resulting in a crash.

Comment 4

[K Chayka]

Win98 crash problem seems to be fixed in build 2000030708

Comment 5

[joki (gone)]

Using the http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6193
testcase on WinNT I've been able to get this to crash a couple of different 
ways.  Both are in PreHandleEvent in the NS_DEACTIVATE message handling.  One is
here:

      // Suppress the command dispatcher for the duration of the
      // de-activation.  This will cause it to remember the last
      // focused sub-window and sub-element for this top-level
      // window.
      nsCOMPtr<nsIDOMWindow> rootWindow;
      nsCOMPtr<nsPIDOMWindow> ourWindow = do_QueryInterface(ourGlobal);
   -->ourWindow->GetPrivateRoot(getter_AddRefs(rootWindow));
      nsCOMPtr<nsIDOMDocument> rootDocument;
      rootWindow->GetDocument(getter_AddRefs(rootDocument));

with a null ourWindow pointer.  The other is here:

            nsEventStatus status = nsEventStatus_eIgnore;
            nsEvent event;
            event.eventStructType = NS_EVENT;
            event.message = NS_BLUR_CONTENT;
            nsCOMPtr<nsIEventStateManager> esm;
            oldPresContext->GetEventStateManager(getter_AddRefs(esm));
            esm->SetFocusedContent(gLastFocusedContent);
            gLastFocusedContent->HandleDOMEvent(oldPresContext, &event, nsnull, 
NS_EVENT_FLAG_INIT, &status); 
            esm->SetFocusedContent(nsnull);
         -->NS_RELEASE(gLastFocusedContent);

with a null gLastFocusedContent.  I'm also going to attach the stack from the 
latter case.  Passing this on to saari.

Comment 6

[joki (gone)]

Attachment: Stack trace

Comment 7

[saari (gone)]

Fixed

Comment 8

[saari (gone)]

really fixed... does seamonkey just not like setting resolution state?

Comment 9

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 10

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial