10511 - crash when closing browser or Composer window via keybinding

Status: VERIFIED DUPLICATE of bug 53838

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

Description

[Kathleen :Brade]

on Mac, add the following keybinding (if it isn't already present):
in mozilla/editor/ui/composer/content/EditorAppShell.xul, below </script> add:
 <keyset>
   <key id="wcmdkey" disabled="false" shift="false" command="true" alt="false"
key="w" onkeypress="EditorClose()"/>
 </keyset>

to reproduce:
(1) bring up editor from Task menu
(2) click in editor window to give it focus
(3) press Command-W to close (Control-W on other platforms)
Crash in nsEventListenerManager::HandleEvent (this and the xuldoc have been
freed)

Comment 1

[joki (gone)]

I think I may know what this one is.  We currently hold onto the world via the
PresShell for event dispatching so it doesn't die beneath us.  But when we
added the bubbling to chrome thing we're now passing the event out of the
current PresShell and therefore outside the safety zone.  As a result, when we
close the window from the ctrl-w we wipe out the xul doc and its
listenermanager while we're still processing and end up dying inside the
listenermanager with a bad pointer.

So for possible solutions I guess the first that comes to mind is we could
addref the chromedocument pointer in globalwindow before passing anything to
it.  Or we can try to find a way to safe its presshell.  Thoughts?

Comment 2

[Kathleen :Brade]

see bug #10515 for enabling Control-W on non-Macintosh platforms (plus you'll
need to add the following to nsEventStateManager.cpp)
around line 123 add:
    case NS_KEY_PRESS:
      {
        nsKeyEvent *keyEvent = (nsKeyEvent *)aEvent;
        if (keyEvent->isControl) {
          keyEvent->charCode += 64;
        }
      }
      break;

Comment 3

[leger]

brade, is this particular bug Mac specific?

Comment 4

[Kathleen :Brade]

o, Joki was able to make some hacks to his build to be able to reproduce this bug

on Windows.  (bug #10515 is for part of the code to enable the keybinding code so

this bug can be reproduced on non-Macintosh platforms)

Comment 5

[rubydoo123]

what's the status of this bug? joki -- do you have a milestone in mind?

Comment 6

[Claudius Gayle]

I'm closing bug 16867 as a dupe of this but I'm copying the stack trace from that bug
over here.

Result: crash in nsEventListenerManager::HandleEvent() double-freeing
mKeyListener. Stack below

nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4, nsEventStatus &
nsEventStatus_eIgnore) line 814 + 9 bytes
XULDocumentImpl::HandleDOMEvent(XULDocumentImpl * const 0x01cb3e30,
nsIPresContext & {...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8,
unsigned int 4, nsEventStatus & nsEventStatus_eIgnore) line 2211
nsXULElement::HandleDOMEvent(nsXULElement * const 0x01d47ca0, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4,
nsEventStatus & nsEventStatus_eIgnore) line 2746 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x01f08d90, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4,
nsEventStatus & nsEventStatus_eIgnore) line 2744
nsXULElement::HandleDOMEvent(nsXULElement * const 0x01f0a2c0, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4,
nsEventStatus & nsEventStatus_eIgnore) line 2744
nsXULElement::HandleDOMEvent(nsXULElement * const 0x01f0bce0, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4,
nsEventStatus & nsEventStatus_eIgnore) line 2744
nsXULElement::HandleDOMEvent(nsXULElement * const 0x01f0b6c0, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 4,
nsEventStatus & nsEventStatus_eIgnore) line 2744
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0230f054,
nsIPresContext & {...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8,
unsigned int 4, nsEventStatus & nsEventStatus_eIgnore) line 2891
nsDocument::HandleDOMEvent(nsDocument * const 0x02313530, nsIPresContext &
{...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x0012f8f8, unsigned int 1,
nsEventStatus & nsEventStatus_eIgnore) line 2379
nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x023131ac,
nsIPresContext & {...}, nsEvent * 0x0012fbc8, nsIDOMEvent * * 0x00000000,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 188 + 41 bytes
PresShell::HandleEvent(PresShell * const 0x02392554, nsIView * 0x023a51c0,
nsGUIEvent * 0x0012fbc8, nsEventStatus & nsEventStatus_eIgnore) line 2164 + 39
bytes
nsView::HandleEvent(nsView * const 0x023a51c0, nsGUIEvent * 0x0012fbc8,
unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 834
nsView::HandleEvent(nsView * const 0x023a4210, nsGUIEvent * 0x0012fbc8,
unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsView::HandleEvent(nsView * const 0x023a42a0, nsGUIEvent * 0x0012fbc8,
unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsView::HandleEvent(nsView * const 0x02392930, nsGUIEvent * 0x0012fbc8,
unsigned int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsViewManager::DispatchEvent(nsViewManager * const 0x02392e30, nsGUIEvent *
0x0012fbc8, nsEventStatus & nsEventStatus_eIgnore) line 1739
HandleEvent(nsGUIEvent * 0x0012fbc8) line 63
nsWindow::DispatchEvent(nsWindow * const 0x023927f4, nsGUIEvent * 0x0012fbc8,
nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbc8) line 422
nsWindow::DispatchKeyEvent(unsigned int 133, unsigned short 0, unsigned int 13)
line 2049 + 15 bytes
nsWindow::OnKeyDown(unsigned int 13, unsigned int 28) line 2249 + 25 bytes
nsWindow::ProcessMessage(unsigned int 256, unsigned int 13, long 1835009, long
* 0x0012fdf4) line 2598 + 40 bytes
nsWindow::WindowProc(HWND__ * 0x006405f2, unsigned int 256, unsigned int 13,
long 1835009) line 579 + 27 bytes
USER32! 77e71268()

Comment 7

[Claudius Gayle]

*** Bug 16867 has been marked as a duplicate of this bug. ***

Comment 8

[ekrock's old account (dead)]

Marking [CRASH].

Comment 9

[joki (gone)]

Moving crash bugs into M13.

Comment 10

[joki (gone)]

Mass-moving excess bugs to M14

Comment 11

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 12

[joki (gone)]

I left this open as long as I did because I thought I remembered a continuing 
problem.  However we seem to have long since gotten past this so closing as 
fixed.

Comment 13

[John Unruh]

Verified fixed.

Comment 14

[Kathleen :Brade]

reopen bug; I am seeing this again.
nominate for nsbeta3, rtm, etc since this is a nasty regression which users may
run into a lot.

Comment 15

[Kathleen :Brade]

note: my crashes came by closing the browser window with command-W on Macintosh

Comment 16

[Dan Rosen]

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

Comment 17

[Scott Brodmerkle]

Verified dupe.