Created attachment 570190 [details] "Restore Windows" dialog screenshot After a startup crash (or two?), OS X displays a dialog asking whether is should try again to restore the applications' windows (screenshot attached): == 'The application “NightlyDebug” unexpectedly quit while trying to restore its windows. Do you want to try to restore its windows again?' [Don't Restore Windows] [Restore Windows] == I believe this quote from the developer documentation is related to the dialog: "All Cocoa window and view objects save basic information about their size and location, plus information about other attributes that might affect the way they are currently displayed."  I haven't notice any difference between the result of clicking the two buttons. If there is no difference in the buttons because we haven't implemented some new Lion APIs then we should consider disabling this dialog to prevent confusion. I'm adding our own startup crash detection in bug 294260 and it will be confusing for the user to see both dialogs. Supposedly this feature can be disabled per application using the following command: defaults write com.postbox-inc.postbox NSQuitAlwaysKeepsWindows -int 0 This may be related to bug 639707 but I can't seem to find this OS X dialog explicitly documented to know for sure.  https://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW20 "Writing Out the State of Your Windows and Custom Objects"  http://support.postbox-inc.com/entries/20301018-can-t-start-postbox-on-os-x-lion-after-a-crash-blocked-by-restore-windows-dialog#overview
Do you have a way to reproduce this? Is the crash related to the dialog, or might any startup crash trigger this dialog? For myself, I've never seen this dialog. But I don't run very often on OS X Lion, and I'm not sure I've ever had an FF startup crash on Lion.
Do you have a Breakpad ID for the crash that triggered this dialog? (Yes, I think Breakpad is disabled in debug builds, but I'm asking just in case.)
Created attachment 575991 [details] [diff] [review] Force crash with null pointer if FORCECRASH=1 (In reply to Steven Michaud from comment #1) > Do you have a way to reproduce this? I'm writing code (attached) to cause a crash in order to test my crash detection. > Is the crash related to the dialog, or might any startup crash trigger this > dialog? I don't think the crash is related to the dialog. This dialog conflicts with the crash detection I'm adding so I think we should either act specially after the OS detects a startup crash or disable this feature and let the startup crash detection in bug 294260 handle it. > For myself, I've never seen this dialog. But I don't run very often on OS X > Lion, and I'm not sure I've ever had an FF startup crash on Lion. I'd never seen it either before forcing a startup crash. (In reply to Steven Michaud from comment #2) > Do you have a Breakpad ID for the crash that triggered this dialog? (Yes, I > think Breakpad is disabled in debug builds, but I'm asking just in case.) There's no crash report but you can try the patch or make your own crash to see what happens. Other than this dialog interfering with the UI added in bug 294260 I mostly wanted to make sure the team was aware of this OS feature so we can handle it appropriately.
I've played with your patch on Lion, and have seen the dialog you report a few times, but not consistently. Whether I ever see the dialog seems to depend on how I build the tree. And when I do see the dialog the browser never crashes (which is very weird). So far I've only tested on OS X 10.7.2. But (of course) I'll also need to test on other versions of OS X. I suspect it's going to take a long time to get to the bottom of this -- I suspect there are several different factors involved. I'm not going to have that kind of time for a while.
Note that if you add the following to the browser's Info.plist, the FORCECRASH environment variable will be set whenever you run the browser by double-clicking on it: <key>LSEnvironment</key> <dict> <key>FORCECRASH</key> <string>1</string> </dict>
Provisionally assigning this bug to myself, since it seems important. But like I said I won't have time to work on it for a while. So others should feel free to take it and work on it.
Assignee: nobody → smichaud
You need to log in before you can comment on or make changes to this bug.