crash after repeated blur and focus while waiting for dialog

VERIFIED FIXED in M15

Status

()

Core
Event Handling
P1
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: dbaron, Assigned: saari (gone))

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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
(Reporter)

Comment 1

19 years ago
Created attachment 6193 [details]
testcase described in bug

Comment 2

19 years ago
Created attachment 6240 [details]
another similar test case that causes Win98 crash

Comment 3

19 years ago
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

19 years ago
Win98 crash problem seems to be fixed in build 2000030708

Updated

19 years ago
Severity: normal → critical
Keywords: crash

Comment 5

19 years ago
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.
Assignee: joki → saari

Comment 6

19 years ago
Created attachment 6352 [details]
Stack trace
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M15
(Assignee)

Comment 7

18 years ago
Fixed
(Assignee)

Comment 8

18 years ago
really fixed... does seamonkey just not like setting resolution state?
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 10

18 years ago
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.