STR in Firefox: 1) Right-click customize the toolbar 2) Drag location bar off of toolbar, on to palette (to remove it from chrome) 3) Done. 4) Crash. Seems to be mac-specific, or at least, I can't reproduce it on Windows. Verified on Tiger and Leopard with current trunk. Stack dump 1 (from Johnath's tests, Tiger): EXC_BAD_ACCESS (0x0001) KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 0 + 0 1 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) + 675 2 PresShell::HandlePositionedEvent(nsIView*, nsIFrame*, nsGUIEvent*, nsEventStatus*) + 279 3 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*) + 935 4 nsViewManager::HandleEvent(nsView*, nsPoint, nsGUIEvent*, int) + 71 5 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) + 2555 6 HandleEvent(nsGUIEvent*) + 54 7 nsChildView::DispatchEvent(nsGUIEvent*, nsEventStatus&) + 165 8 nsChildView::DispatchWindowEvent(nsGUIEvent&) + 34 9 nsChildView::DispatchMouseEvent(nsMouseEvent&) + 35 Stack 2 (from Gavin's test, Leopard): Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libgklayout.dylib 0x11eeea5c nsDOMUIEvent::GetClientPoint() + 284 1 libgklayout.dylib 0x11eeed5b nsDOMUIEvent::DuplicatePrivateData() + 25 2 libgklayout.dylib 0x11ef6efe nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*) + 1220 3 libgklayout.dylib 0x11d3f49e PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) + 402 4 libgklayout.dylib 0x11d3ffe8 PresShell::HandleEventWithTarget(nsEvent*, nsIFrame*, nsIContent*, nsEventStatus*) + 62 5 libgklayout.dylib 0x11ee847f nsEventStateManager::CheckForAndDispatchClick(nsPresContext*, nsMouseEvent*, nsEventStatus*) + 387 6 libgklayout.dylib 0x11ee8a23 nsEventStateManager::PostHandleEvent(nsPresContext*, nsEvent*, nsIFrame*, nsEventStatus*, nsIView*) + 1047 7 libgklayout.dylib 0x11d3f5b7 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) + 683 8 libgklayout.dylib 0x11d40111 PresShell::HandlePositionedEvent(nsIView*, nsIFrame*, nsGUIEvent*, nsEventStatus*) + 277 9 libgklayout.dylib 0x11d44c1f PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*) + 959 10 libgklayout.dylib 0x11fe03c1 nsViewManager::HandleEvent(nsView*, nsPoint, nsGUIEvent*, int) + 71 11 libgklayout.dylib 0x11fe3208 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) + 2606 12 libgklayout.dylib 0x11fdd400 HandleEvent(nsGUIEvent*) + 54 13 libwidget_mac.dylib 0x119dcc5f nsChildView::DispatchEvent(nsGUIEvent*, nsEventStatus&) + 165 14 libwidget_mac.dylib 0x119db97e nsChildView::DispatchWindowEvent(nsGUIEvent&) + 34 15 libwidget_mac.dylib 0x119db9b1 nsChildView::DispatchMouseEvent(nsMouseEvent&) + 39 16 libwidget_mac.dylib 0x119dec3f -[ChildView mouseUp:] + 365 17 libwidget_mac.dylib 0x119d5029 -[PopupWindow sendEvent:] + 673 18 com.apple.AppKit 0x956b5a2c -[NSApplication sendEvent:] + 2766 19 com.apple.AppKit 0x95613705 -[NSApplication run] + 847 20 libwidget_mac.dylib 0x119d28ee nsAppShell::Run() + 52 21 libtoolkitcomps.dylib 0x004cc1a1 nsAppStartup::Run() + 45 22 XUL 0x0004d666 XRE_main + 14002 23 org.mozilla.firefox 0x00002e55 main + 509 24 org.mozilla.firefox 0x000025d8 _start + 210 25 org.mozilla.firefox 0x00002505 start + 41

Once I rebuilt with smaug's latest DOMUIEvent patch, I get essentially the same stack as Johnathan's.

Any chance to get a bit more useful stack? Line numbers and all...

Could anyone here try for example https://bugzilla.mozilla.org/attachment.cgi?id=287985 or https://bugzilla.mozilla.org/attachment.cgi?id=288391? The latter one causes an assertion on mac, which is the reason I had to back it out, but should be still worth to try. (Would be great if someone could actually debug that assertion, since I don't have a mac and I just have to guess what the problem could be)

(In reply to comment #2) > Any chance to get a bit more useful stack? Line numbers and all... #0 0x12ff9da8 in nsEventStateManager::PostHandleEvent at nsEventStateManager.cpp:2382 #1 0x12d0c646 in PresShell::HandleEventInternal at nsPresShell.cpp:5812 #2 0x12d0c8b1 in PresShell::HandlePositionedEvent at nsPresShell.cpp:5681 #3 0x12d0e79a in PresShell::HandleEvent at nsPresShell.cpp:5517 #4 0x131a166c in nsViewManager::HandleEvent at nsViewManager.cpp:1296 #5 0x131a24ed in nsViewManager::DispatchEvent at nsViewManager.cpp:1252 #6 0x131980d9 in HandleEvent at nsView.cpp:168 #7 0x11b26070 in nsChildView::DispatchEvent at nsChildView.mm:1347 #8 0x11b20a08 in nsChildView::DispatchWindowEvent at nsChildView.mm:1360 #9 0x11b20a48 in nsChildView::DispatchMouseEvent at nsChildView.mm:1372 #10 0x11b26750 in -[ChildView mouseUp:] at nsChildView.mm:2575 #11 0x11b1adff in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:1720 #12 0x956b5a2c in -[NSApplication sendEvent:] #13 0x95613705 in -[NSApplication run] #14 0x11b16eeb in nsAppShell::Run at nsAppShell.mm:565 #15 0x1274ffa4 in nsAppStartup::Run at nsAppStartup.cpp:170 #16 0x000fa83f in XRE_main at nsAppRunner.cpp:3142 #17 0x000026d3 in main at nsBrowserApp.cpp:153

I also see: ###!!! ASSERTION: Null pres shell: 'mShell', file ../../dist/include/layout/nsPresContext.h, line 178 ###!!! ASSERTION: Null pres shell: 'mShell', file ../../dist/include/layout/nsPresContext.h, line 178 I'll try those attachments next.

(In reply to comment #4) > Could anyone here try for example > https://bugzilla.mozilla.org/attachment.cgi?id=287985 or > https://bugzilla.mozilla.org/attachment.cgi?id=288391? Neither of those attachments seem to have an effect on this crash (applied them separately and rebuilt in view, layout/base, and layout/build).

Actually if you applied that weakframe patch, compiling only in those directories may not be enough. But still, also the other patch should have helped.

I think I need to back out bug 401528. Anyone willing to do that now? I have time tomorrow.

Backed out bug 401528. This should be fixed. Someone who can reproduce, please verify.