The Session Restore prompt causes various issues such as blocking DDE under Windows (bug 371031), potentially allowing to discard the session under OS X (bug 381386), appearing even when there's no browser window to restore into (bug 365581) and probably a few others. The alternatives seem to be the following: 1. Keep the prompt where it is and prevent any browser window from opening while it is displayed. - This might not only be annoying (stupid prompt getting in the way), we'd also have to have a way to keep track of all the URLs the user tried to open while the prompt was displayed (using a command line handler hack). Won't fix bug 365581, though. 2. Delay the prompt as suggested in bug 354894 but still prevent any further browser window from opening. - Similar issues as before, although intercepting opened URLs can happen at a later moment (i.e. just pick them out at the "domwindowopened" notification and close the windows without actually displaying them). We'll just have to make sure to open new windows/tabs accordingly afterwards. 3. Allow further browser windows to be opened while the prompt is displayed. - With the prompt shown plus one browser window opened, what should be restored in case of a crash at that point? Probably both the openend and the to-be-restored windows. Such a solution will require further coupling between nsSessionStore and nsSessionStartup. 4. Use an error page instead of the prompt, which would either restore the session replacing itself and adding new windows as needed, or just replace itself with nsBrowserHandler.defaultArgs (i.e. homepage(s) or blank tab). - Would require a new about:crashedsession page (or similar for the error page) and might be mistaken for a homepage-could-not-be-loaded error page. Otherwise the least intrusive and best handled (by the current implementation) solution. I'd propose to go with either solution 2 or solution 4. 2 should be doable with less code, but in the age of going non-modal, 4 might be preferable...

This approach intercepts any browser window opened while the Session Restore prompt is shown and kills them as soon as possible, staging their URLs for later opening. Depending on the extensions used, this may however have unintended side effects, as browser windows may be unloaded without ever having been properly loaded before. OTOH this shouldn't really happen too often, as most people will probably just acknowledge the Session Restore prompt without trying anything fancy.

Would this cause any flicker as those windows are opened/closed behind the session restore prompt?

(In reply to comment #2) It unfortunately does. Not sure what could be done against that, though.

Comment on attachment 265968 [details] [diff] [review] alternative 2 Canceling ui-r? until a better solution comes up (if possible more generally applying to all potential startup prompts).

I would like to see option 4 implemented or possibly a drop down bar. once you've started browsing option to restore into new windows would be default with middle click loading tabs into existing windows overwriting would be implemented by a check box "about:restore" would also allow other features to be added to an existing interface. view a list of open tabs and remove tabs before restore save restore session for later extensions could interact with the page and allow time-delayed auto-restore, so that you can avoid crash-loops (the whole point of the dialogue) with no other side effects alternatives *a drop down bar would the problems of the current method but not be extensible *a non-modal dialogue would also solve the problems but still be a pain and stick out in the new dialogue-free interface

Townsend's NTT extension is also attempting has a "restore session" function that works after firefox is up. http://www.oxymoronical.com/web/firefox/nightly/features xref Bug 380862

There's an extension implementing option #4 attached to bug 448976. Feedback is welcome in that bug.

An implementation of proposal #4 has got ui-review+ in bug 448976 which effectively fixes this bug.