Loading the BananaBread demo (Level 1, high resolution) and going FullScreen is repeatedly crashing on my mac. This is a new MacBook Air, with Mountain Lion. I think my Nightly was a few days old and it was crashing on this, and I updated and it's still crashing. So it's probably been a bug for a little while. The crash report isn't getting a stack ("@ EMPTY: no crashing thread identified; corrupt dump"). Also, the crash reporter is not preventing the OS X crash dialog from popping up. Page that generates the crash: https://developer.mozilla.org/en-US/demos/detail/bananabread/launch Crash report (such as it is): https://crash-stats.mozilla.com/report/index/bp-1fe93748-3019-4b14-b7c6-338322121024 Since this is happening on going to full screen, I'm guessing this belongs in gfx, but I'm not sure. Dave

Do you have a stack trace (see https://developer.mozilla.org/docs/How_to_get_a_stacktrace_for_a_bug_report#Alternative_ways_to_get_a_stacktrace)?

I got the same issue at a conference recently, it crashed only when using screen mirroring with a vga adapter for me, and all stack traces were empty like yours. These are the STRs for me (don't have that setup to try here): - attach vga projector and set screen to mirror - launch the game - go fullscreen -> crash deselecting screen mirroring stopped the crash.

Jeff, can you get together with dherman and take a look at this?

Foo, now I can't reproduce in my updated Nightly. Also, I couldn't find the CrashReporter logs using the instructions pointed to in Comment 1 (have they changed for Mountain Lion?). Maybe I can do a build using a week-old snapshot of the tree, if jgilbert wants to help me look into this. Dave

Using Mac 21.0a1 (2013-01-19) 1) Load http://maxogden.github.com/voxel-engine/ 2) click a few times in the document 3) Wait until the Full Screen prompt comes up 4) Press accept After a few seconds, we crash. Looks like we are blowing out the stack. Maybe the same MouseEnterExit is being dispatched to the child view during the handling of the child view. #24020 0x00000001021c6f16 in nsViewManager::DispatchEvent (this=0x113c49250, aEvent=0x7fff5fbfb9c8, aView=0x113c08860, aStatus=0x7fff5fbfb748) at /Users/dougt/builds/mozilla-central/view/src/nsViewManager.cpp:718 #24021 0x00000001021c4795 in nsView::HandleEvent (this=0x113c08860, aEvent=0x7fff5fbfb9c8, aUseAttachedEvents=false) at /Users/dougt/builds/mozilla-central/view/src/nsView.cpp:1010 #24022 0x00000001030c032f in nsChildView::DispatchEvent (this=0x1001dfb10, event=0x7fff5fbfb9c8, aStatus=@0x7fff5fbfb8bc) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1478 #24023 0x00000001030c03b6 in nsChildView::DispatchWindowEvent (this=0x1001dfb10, event=@0x7fff5fbfb9c8) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1486 #24024 0x00000001030c8fe5 in -[ChildView handleMouseMoved:] (self=0x100133f40, _cmd=0x7fff90db9b4d, theEvent=0x14c250c80) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:3416 #24025 0x00000001030d084c in ChildViewMouseTracker::MouseMoved (aEvent=0x14c250c80) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:4884 #24026 0x00000001030b697d in -[BaseWindow mouseMoved:] (self=0x11631f6f0, _cmd=0x7fff97c37335, aEvent=0x14c250c80) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsCocoaWindow.mm:2583 #24027 0x00000001030bf4a7 in nsChildView::SynthesizeNativeMouseEvent (this=0x1001dfb10, aPoint=@0x7fff5fbfbc90, aNativeMessage=5, aModifierFlags=0) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1227 #24028 0x00000001030d1d66 in nsChildView::SynthesizeNativeMouseMove (this=0x1001dfb10, aPoint=<value temporarily unavailable, due to optimizations>) at nsChildView.h:473 #24029 0x0000000101ddc2db in nsEventStateManager::GenerateMouseEnterExit (this=0x113c132e0, aEvent=0x7fff5fbfccc8) at /Users/dougt/builds/mozilla-central/content/events/src/nsEventStateManager.cpp:4197 #24030 0x0000000101ddb216 in nsEventStateManager::PreHandleEvent (this=0x113c132e0, aPresContext=0x113c25310, aEvent=0x7fff5fbfccc8, aTargetFrame=0x164768040, aStatus=0x7fff5fbfca48) at /Users/dougt/builds/mozilla-central/content/events/src/nsEventStateManager.cpp:1066 #24031 0x0000000101789c37 in PresShell::HandleEventInternal (this=0x113cf07e0, aEvent=0x7fff5fbfccc8, aStatus=0x7fff5fbfca48) at /Users/dougt/builds/mozilla-central/layout/base/nsPresShell.cpp:6574 #24032 0x00000001017890e1 in PresShell::HandlePositionedEvent (this=0x113cf07e0, aTargetFrame=0x164768040, aEvent=0x7fff5fbfccc8, aEventStatus=0x7fff5fbfca48) at /Users/dougt/builds/mozilla-central/layout/base/nsPresShell.cpp:6353 #24033 0x000000010178834d in PresShell::HandleEvent (this=0x113cf07e0, aFrame=0x100e11020, aEvent=0x7fff5fbfccc8, aDontRetargetEvents=false, aEventStatus=0x7fff5fbfca48) at /Users/dougt/builds/mozilla-central/layout/base/nsPresShell.cpp:6155 #24034 0x00000001021c6f16 in nsViewManager::DispatchEvent (this=0x113c49250, aEvent=0x7fff5fbfccc8, aView=0x113c08860, aStatus=0x7fff5fbfca48) at /Users/dougt/builds/mozilla-central/view/src/nsViewManager.cpp:718 #24035 0x00000001021c4795 in nsView::HandleEvent (this=0x113c08860, aEvent=0x7fff5fbfccc8, aUseAttachedEvents=false) at /Users/dougt/builds/mozilla-central/view/src/nsView.cpp:1010 #24036 0x00000001030c032f in nsChildView::DispatchEvent (this=0x1001dfb10, event=0x7fff5fbfccc8, aStatus=@0x7fff5fbfcbbc) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1478 #24037 0x00000001030c03b6 in nsChildView::DispatchWindowEvent (this=0x1001dfb10, event=@0x7fff5fbfccc8) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1486 #24038 0x00000001030c8fe5 in -[ChildView handleMouseMoved:] (self=0x100133f40, _cmd=0x7fff90db9b4d, theEvent=0x14c251410) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:3416 #24039 0x00000001030d084c in ChildViewMouseTracker::MouseMoved (aEvent=0x14c251410) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:4884 #24040 0x00000001030b697d in -[BaseWindow mouseMoved:] (self=0x11631f6f0, _cmd=0x7fff97c37335, aEvent=0x14c251410) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsCocoaWindow.mm:2583 #24041 0x00000001030bf4a7 in nsChildView::SynthesizeNativeMouseEvent (this=0x1001dfb10, aPoint=@0x7fff5fbfcf90, aNativeMessage=5, aModifierFlags=0) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsChildView.mm:1227 #24042 0x00000001030d1d66 in nsChildView::SynthesizeNativeMouseMove (this=0x1001dfb10, aPoint=<value temporarily unavailable, due to optimizations>) at nsChildView.h:473 #24043 0x0000000101de9a53 in nsEventStateManager::SetPointerLock (this=0x14c90fa00, aWidget=0x1001dfb10, aElement=0x1393dc6e0) at /Users/dougt/builds/mozilla-central/content/events/src/nsEventStateManager.cpp:4287 #24044 0x0000000101bcef56 in nsDocument::SetPointerLock (this=0x13f85ca00, aElement=0x1393dc6e0, aCursorStyle=36) at /Users/dougt/builds/mozilla-central/content/base/src/nsDocument.cpp:10153 #24045 0x0000000101bce6e2 in nsDocument::RequestPointerLock (this=0x13f85ca00, aElement=0x1393dc6e0) at /Users/dougt/builds/mozilla-central/content/base/src/nsDocument.cpp:10038 #24046 0x0000000101bed9ee in nsAsyncPointerLockRequest::Run (this=0x15718e090) at /Users/dougt/builds/mozilla-central/content/base/src/nsDocument.cpp:9872 #24047 0x00000001039082c4 in nsThread::ProcessNextEvent (this=0x10bf07190, mayWait=false, result=0x7fff5fbfd3c3) at /Users/dougt/builds/mozilla-central/xpcom/threads/nsThread.cpp:627 #24048 0x0000000103870722 in NS_ProcessPendingEvents_P (thread=0x10bf07190, timeout=20) at nsThreadUtils.cpp:188 #24049 0x0000000103114a0f in nsBaseAppShell::NativeEventCallback (this=0x10c92a1f0) at /Users/dougt/builds/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:97 #24050 0x00000001030a647c in nsAppShell::ProcessGeckoEvents (aInfo=0x10c92a1f0) at /Users/dougt/builds/mozilla-central/widget/cocoa/nsAppShell.mm:387 #24051 0x00007fff8f4d0101 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()

STR in comment 5 doesn't crash for me on Windows.

I think this is a bug in fullscreen handling. We need to do something to SynthesizeNativeMouseMove usage.

(In reply to Olli Pettay [:smaug] from comment #7) > I think this is a bug in fullscreen handling. We need to do something to > SynthesizeNativeMouseMove usage. What do you mean?

ESM should not re-dispatch synth event if it is doing so already. That should take care of the stack overflow. And SynthesizeNativeMouseMove is there for pointerlock+fullscreen, atm. (but indeed, more about pointerlock)

(In reply to Olli Pettay [:smaug] from comment #9) > And SynthesizeNativeMouseMove is there for > pointerlock+fullscreen, atm. > (but indeed, more about pointerlock) I'm afraid I still don't understand this part.

The pointer lock code in the ESM dispatches a synthetic mouse move after every real mouse move to re-center the hardware pointer on screen. I think this is to stop the mouse movement being clamped at the edge of the screen, i.e. to allow reporting of further mouse movement.

Ah thanks.

A simpler testcase: http://pearce.org.nz/fullscreen/pointerlock-position.html STR: 1. Open testcase on *non-primary* monitor on MacOSX. 2. Enter fullscreen + pointerlock. 3. Crash. The problem: In nsEventStateManager::GenerateMouseEnterExit() if we determine that a mouse move event is synthetic and was dispatched to re-center while pointer locked, we don't dispatch another synthetic mouse move to re-center the pointer. However the code to determine that a mouse move is a synthetic-centering event relies on the calculation of the center of the widget's client area calculated in GetWindowInnerRectCenter(), and GetWindowInnerRectCenter() is wrong on MacOSX. GetWindowInnerRectCenter() relies on the value returned by nsIWidget::GetScreenBounds(nsIntRect&), but on MacOSX that value is always (0,0,screenWidth,screenHeight) on all monitors, whereas the code in GetWindowInnerRectCenter assumes that GetScreenBounds() is in screen coords, relative to the top left of the primary monitor, i.e. we assume that the screen bounds are not always (0,0,w,h) for non-primary monitors (this is the behaviour on Windows). I'm not sure if this is a bug in the MacOSX widget's GetScreenBounds() implementation or if it's a bug in Window widget backend's implementation's, or if this difference is intentional. In GetWindowInnerRectCenter() I calculate the center of the client area by subtracting window.mozInner{X,Y} in order to get back from screen coords to widget coords, as window.mozInner{X,Y} is in screen coords relative to the primary display, but then for non-primary monitors on MacOSX this calculation will be wrong. Thus the calculated center ends up lying outside the screen bounds, and when we dispatch the synthetic mouse event the event's coords are clamped to screen coords, so the aEvent->refPoint!=center test in GenerateMouseEnterExit doesn't fire and we dispatch another synthetic mouse event, ad infinitum, and then we get a stack overflow. If I calculate the center of the client area as: nsIWidget::GetClientOffset() + nsIntPoint(window.mozInnerWidth/2, window.mozInnerHeight/2), things work as expected.

The problem here is that nsChildView doesn't implement GetScreenBounds, so we're falling back to using nsBaseWidget::GetScreenBounds(), which just returns mBounds. nsBaseWidget::mBounds is relative to the parent widget for non-top-level Windows, so nsChildView::GetScreenBounds() is returning the bounds as offset from its parent window, not in screen coords as it's supposed to. This is causing the pointer lock logic for re-centering the mouse to fail, as I outlined in my previous comment above. This patch implements nsChildView::GetScreenBounds(). Greenish on Try: https://tbpl.mozilla.org/?tree=Try&rev=1fcd39184600

Verified fixed in Nightly 21.0a1 (2013-02-12).