User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008033005 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008033005 Minefield/3.0pre I propose that there be an option available to the user to choose which tabs they would like to restore after a Firefox crash. The main reason being that when a certain tab crashes the browser, restoring the session will cause the browser-crashing tab to also be restored which can cause the browser to crash all over again putting you in a never ending loop if you wanted to restore the other tabs you were working in. Which forces you to start a new session and lose any tabs you had open whether you wanted them restored or not. I personally have come across this situation and I'm sure many other users have too. I have brought up this idea in the forums and it has been received well and backed by multiple posters. You can see the thread here: http://forums.mozillazine.org/viewtopic.php?t=642945 A few of the ideas that have been proposed are as follows: Option 1: On the box that pops up asking you if you want to "Restore previous session" or "Start New Session", add a checkbox underneath these buttons that says something like "Let me choose which tabs to restore". This checkbox would be unchecked by default in which case the function of the 2 session option buttons would be unchanged from their current functions. However, if the user did check the box and click "Restore previous session", then a second box would come up with the list of tabs that were open when the crash occured and there would be a checkbox next to each tab title. All boxes would be checked by default. They could then uncheck any they do not want to restore and click OK. Option 2: Instead of checkbox as proposed above in Option 1, you have a "Show Details..." button that has a list of the tabs that were opened when the crash occured which are all checked by default. The user can then uncheck any they wish to uncheck and then restore the session. Option 3: Eliminate the "Restore from previous session" and "Start new session" dialog box completely and change it to an error page that comes up after the browser has been restarted following a crash. This error page would look similar to other Firefox error pages and have a message saying the browser has crashed and have a list of tabs that were open when the crash occured and allow them to reopen any of these they wish. I may be posting a mockup of this as an attachment. This is obviously way too late to make Firefox 3.0, but I hope it is considered for a future release. Reproducible: Always

Here is a mockup image for Option 3 above.

Another option, if the cause of the crash can be pinned down to a given tab, would be to put an error page on that tab only, but restore the others. I appreciate that this might be somewhat difficult, but thought I'd throw it out there.

We collect the URL in the tab that was open when the browser crashed, and the crash reporter could pass that back to the app (via environment variable or whatever), and it's often the cause of the crash, but not always. Would be easy to do from the crashreporter side.

Here is a mockup image for Option 2 of the original post showing a "Show Details" button on the Session Restore dialog box.

Option 2 looks much more usable than Option 3. With a little visual refinement, it would add some non-intrusive functionality to the restore process. Very nice.

I think Option 2 pretty much supersedes Option 1 as it looks better and seems more intuitive. So, we are pretty much down to 2 options (unless Option 1 is easier to code than Option 2???) Any other ideas are welcomed.

FWIW, you can already do this... Click "Start New Session" on the box when it comes up, then go to the History menu and pick "Restore from last session..." which gives you the list of all the windows and tabs that were open previously. Adding a third button on the session restore prompt dialog that opened that "Restore from last session..." dialog directly would probably be pretty easy to implement.

Actually, re-reading the original description, I think Option 1 would be the easiest to implement, given what I just pointed out in comment 7.

Ok, well as pointed out in my Comment #6, if Option 1 is easiest to implement, then that me be the way we have to go. I am not a programmer so I can not give any professional opinions on how to perform any of these options or how easy they would be, but I would guess the developers would want to take the easiest route to accomplish the wanted task.

dupe of bug 407117 ?

Although technically a dupe of bug 407117, there's quite some value in this bug. Making the bugs depend on each other, instead.

This was FIXED in bug 448976.

Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090617 Minefield/3.6a1pre ID:20090617031528

in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=7391