Created attachment 241097 [details] Stack The JS here is most likely nsCloseAllWindows.js:76, as that's what I've run into on my XULRunner debug build.
Requesting blocking to get drivers' assessment.
This doesn't happen on Firefox 1.5. Regression.
In XULRunner I'm crashing here: http://lxr.mozilla.org/mozilla1.8/source/widget/src/mac/nsMacWindow.cpp#926 dereferencing a null pointer. It's weird, though, because 'self' and 'mMacEventHandler' are both valid.
I'll bet self->mMacEventHandler isn't, though. ;)
(In reply to comment #5) > I'll bet self->mMacEventHandler isn't, though. ;) It is. That's why it's weird. ;) I think this stack may either be wrong or we're looking at some sort of race condition. If I break here I can't reproduce the crash. And I've seen some instances where the app shuts down normally even when I'm not in the debugger.
Created attachment 241135 [details] Apple report Here is the apple crash data from my PPC crash using RC2 candidate, in case it helps.
I think this is the same as bug 355097.
11 years ago
I did some debugging and when you quit with a sheet open like this we are hiding and destroying the sheet after we hide and destroy its parent window. One way to stop this crash is to hide any sheet children of the parent before hiding the parent. However, while we may want to do that I don't think that code would ever get used if this was handled correctly - we shouldn't be quitting when we have sheets up.
Not a topcrash, very corner case STR, not going to block on this, 188.8.131.52 possibly
11 years ago
If we get a fix please ask for branch approval, but not looking hopeful.
WFM on trunk. Selecting "Quit" from the dock icon while there's a modal alert() dialog open just makes Firefox beep.
(In reply to comment #12) Yeah, I don't think I ever saw this on trunk.
Same happens for Thunderbird when closing the account wizard after opening a compose window while no account was created before. See bug 377350.
Mark, the line where Thunderbird maybe crashes comes from your patch on bug 345564. There you reimported the code which was removed on bug 340592. Does it have something to do with the crash?
Created attachment 272505 [details] [diff] [review] Patch rev. 1 We get calls to nsMacWindow::WindowEventHandler() on a destroyed window. Don't ask me why because that shouldn't happen since we call ::DisposeWindow() in the destructor - there shouldn't be any callbacks after that, but there is. Explicitly deregistering the event handlers fixes it (it also seems to fix bug 355097). The "mMacEventHandler.reset(nsnull)" isn't needed to fix this bug, it's just a safe-guard in case we have more use-after-free issues...
Where is DisposeWindow defined and implemented? lxr can't find it.
I think it's this one: http://developer.apple.com/documentation/mac/Toolbox/Toolbox-258.html
Comment on attachment 272505 [details] [diff] [review] Patch rev. 1 + , mScrollEventHandler(0) + , mWindowEventHandler(0) For consistency, please set these to NULL (not 0 or nsnull, which we use for gecko object pointers, this distinction being used for readability).
Comment on attachment 272505 [details] [diff] [review] Patch rev. 1 sr for branches please.
Comment on attachment 272505 [details] [diff] [review] Patch rev. 1 Only approving blocking bugs for 184.108.40.206
Comment on attachment 272505 [details] [diff] [review] Patch rev. 1 approved for 220.127.116.11, a=dveditz for release-drivers
MOZILLA_1_8_BRANCH mozilla/widget/src/mac/nsMacWindow.cpp 18.104.22.168 mozilla/widget/src/mac/nsMacWindow.h 22.214.171.124 -> FIXED
verified fixed 126.96.36.199 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:188.8.131.52pre) Gecko/2007090303 BonEcho/184.108.40.206pre no crash on steps to reproduce from this bug - adding verified keyword
Works fine with latest 1.8 branch builds. For Firefox 3 it's not possible anymore to close the application over the dock. I filed bug 410170 to cover this issue.
https://litmus.mozilla.org/show_test.cgi?id=5202 has been added to the 2.0 test suite, 3.0 pending depending on behavior change.