A lot of people have suggested implementing some sort of crash recovery, so the browser (and mailnews?) could remember where it was after a crash. This would be embedded into history, so that when you enter or exited a web page it writes that fact. Then when you load after a crash, the browser notices the inconsistent state and see what was entered but not exited. The user should probably be prompted: - attempt to restore session (might cause another crash) - do a history search on these pages, which would bring up a page list that the user could decide what to do with - ignore A page would disappear off the crash list when the history entry died, or it was visited and exited successfully. Not only would this feature be good, it would help capture reproducable test cases of crashing pages for the purposes of bug reporting. This would all dictate a history which was written to disk often, which should happen anyway.

Move to M20.

One caveat here is that you might get stuck in a scenario that .. crashes! In 4.x there was a time where we put you back at the last URL you were at, if it was a crasher, you were hosed. I'm leaning towards "nice idea, has some risk".

Chris, I said that in my original msg: > - attempt to restore session (might cause another crash) That's why there needs to be the ability to bring up a list of these pages and go through them one at a time. If it crashes when you try to restore the session, then you could choose a different option. I'm not advocating anything automatic. This feature might also be useful without a crash occurring, eg if various network errors caused the page not to load.

Adding "crash" keyword to all known open crasher bugs.

this doesn't really need the "crash" keyword does it. Removing crash keyword.

Adding crash keyword.

Move to "Future" milestone.

not sure why the crash kw was readded to this. it's not a crasher

Adding crash to keyword field.

Alphanumerica is working on a feature similar to this called "Total Recall" (http://www.mozillazine.org/chromezone/component.html?component=39) Taking crash out of the summary since Jan's added the crash kw to this three times now (prob. because she just did a query for 'crash' in the summary line and mass-changed the resulting bugs) :-)

more appropriate link is http://www.alphanumerica.com/projects/mozilla/total_recall/ restoring old summary so this shows up in 'crash' summary queries, but putting on [NotACrash,Jan] radar (hehe)

Adding crash keyword.

t h i s i s n o t a c r a s h

Adding crash keyword

<sigh> not a crash

thanks...bulk move...oops...

use the mozdev.org url instead

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: Would be nice, but go use total recall. ;-) Marking nsbeta1-

this is a dup. there is a bout about total recall already. pete used to own it (dunno, if he still does).

Cc'ing pete@alphanumerica.com from bug 36810. Should this bug be marked as a dup of 36810? (I like the way this bug suggests to note in history when you leave a webpage, because that would also be useful for fixing bug 39165.)

Whee, mid-air collisions are fun.

I really don't have a bunch of interest in this anymore due to having no time. Aphrodite has had this feature for many many months. If anyone wants, just grab the code from aphrodite. Or if anyone if sincerely interested i will gladly help them sort it out. Total Recall in Aphrodite saves all of the open windows in the browser at the time of the crash. It saves window x and y coords as well as width and height. Reqeirements: io.js crash.js -pete

kicking out to nobody

The way Opera does it (very reasonable, imo), it to bring up a dialog right at the start to ask: - Start as you left off (may cause another crash) - Start with no open windows - Don't start at all, exit. Can't remember exactly what the options are. Opera doesn't crash much for me :-|. Do we have code in the tree that saves currently opened windows / urls to disk as it happens? What work would be needed here? I'll add mpt for design advice.

This has been implemented as a browser plugin. http://recall.mozdev.org/ It works fine. Give it a spin, i'll take any good patches. The implementation is extremely simple, uses jslib, so other interested developers improving on this code should be easy enough. --pete

When Mozilla restarts, have all windows as they were at the time of the crash, with URLs in the address field, but don't load the URLs. In the content area, put a message something like this: | | Mozilla did not shut down properly the last time it was at this address, and | this may be because of a problem with the page. | | If the problem was not caused by this page, choose `Reload' to view it again. [Debogosifying summary since Jan Leger is no longer here (phew).]

*** Bug 105382 has been marked as a duplicate of this bug. ***

*** Bug 107543 has been marked as a duplicate of this bug. ***

I filed bug 107543 (now set as a dupe of this). I'd just like to add that the UI for this feature could be combined with 102130, so if the browser previously crashed then an extra folder appears on the personal toolbar containing the links that were previously open. Should links accumulate? Perhaps selecting a link from the folder (and a successful open) removes it from the folder (configurable). BTW, I couldn't get total-recall to work on 2001102910 linux build - I get failure code -239 :( (is there a bug-reporting link for total recall?)

no, recall is a small project so i didn't bother setting up bugzilla for it on mozdev. Just mail me any problems you are having and i will try to address them. Thanks --pete pete@mozdev.org

Bug 63094 Is not a dupe of this. It is about manually saving sessions, not just on a crash. Both would depend on something that actually logs the sessions. Form entries should be saved too imho.

*** Bug 150302 has been marked as a duplicate of this bug. ***

*** Bug 150302 has been marked as a duplicate of this bug. ***

*** Bug 156765 has been marked as a duplicate of this bug. ***

Is there some reason why Recall can't be incorporated into the mainline Mozilla tree? It's more likely to stay up to date there (e.g. changes like adding tabs), and it's useful to EVERYONE. We can't guarantee Mozilla will never crash, but we could at least protect the valuable state data from being lost in a crash!

deven: we accept patches. however, I would think that for integration into mozilla, total recall must be able to save the currently open tabs as well.

As far as I saw, recall does not yet support tabbed browsing. I.e. only the first tab in every window is remembered. There is already a bug entered at http://mozdev.org/bugs/show_bug.cgi?id=641 for this.

*** Bug 166233 has been marked as a duplicate of this bug. ***

*** Bug 175184 has been marked as a duplicate of this bug. ***

*** Bug 178785 has been marked as a duplicate of this bug. ***

*** Bug 185182 has been marked as a duplicate of this bug. ***

Please do not forget to handle MailNews. Crashes are _much_ more annoying there. You've typed a long, detailed email for an hour and the machine crashes. Goodbye hard work. For many people, MailNews is a core "content creation" application and should have the same robustness and recovery features as e.g. Word.

RE: comment #36 Not to mention the fact that the OS might crash. Especially if it's windows. Will this recall pages after an OS crash?

yes, its recover pages after a OS crash, as long as there is no Hd or fs problem&#013;&#013;the major problem is that right now recall doesnt work for normal access and never worked for tabs

*** Bug 190716 has been marked as a duplicate of this bug. ***

*** Bug 191399 has been marked as a duplicate of this bug. ***

Taking. This is really a tracking bug. The three main bugs are bug 36810, bug 156765, and bug 63094.

What we need to do now is spec this thing out. If we want to get it to work like Total Recall, fine. If not, fine. In any case, that discussion probably belongs on the newsgroups, not here.

*** Bug 207043 has been marked as a duplicate of this bug. ***

Since Mozilla can already stop and tell me that it's shutting down (so I can see the details &/or send to Netscape), it should be easy to record at the same time all open web page addresses to a simple text file, which I could open with a simple text editor (& cut & paste those I wanted to revisit). That wouldn't require any maintenance or complications. What I actually need: a simple text file list of the open pages to be revisited/investigated if important to the user. That's not as complicated as Crash Recovery tracking appears. 36810 (Autosave URIs of open windows) is a better reassignment for my needs, & would suffice. Total Recall was an ambitious attempt, but doesn't work with mozilla & now defunct.

> Total Recall was an ambitious attempt Heh, Total Recall is as simple as you can get for this type of implementation. The only difference is that I wrote to an rdf file instead of a plain text file. I think it would take a few hours to get Total Recall working again w/ Mozilla trunk. I have to say i'm quite surprised that no one picked up the code and got it working again. If enough people bug me, maybe i'll take the time to get it going again. I have been known to fix Mozilla bugs for beer. hint hint --pete

Ok, I get Total Recall working w/ Mozilla 1.4X. http://recall.mozdev.org/ I still need to hook in tab support and smooth out the rough edges, etc. I'll stay w/ it. --pete

Thanks Pete!

Thanks!! to here we should send the beer? (and any tip how?! i'm in Portugal, i have no idea how can i sent you beer... maybe by email?! 8)

Ok, I just tested the production jar xpi here: http://recall.mozdev.org/installation.html It works now. I had an error on my html page. I forgot the closing "</script>" tag. Next i'll implement tab support, hopefully sometime this week. My local beer distributor is below in case anyone want's to spring for a six pack: :-) Blue Bell Dist. 8 Gates Street Greenlawn, NY 11740 1-3631-261-9100 --pete

Just tested some more. It works on Windows and Linux. Must use Mozilla 4.x or nightlies. I tried using 1.3 and it didn't work. --pete

could you try to find if your local beer distributor have a email or any way to order from the internet? a fast search i dint find then in the net 8) if i knew that fixing this bug was "so easy" with beer, i would have sent you pack a year ago !! 8)

> could you try to find if your local beer distributor have a email or any way to order from the internet? Actually, i've done this once before. ;-) The way the other developer did it, he called the distributor and charged the beer over the phone. Then I went down and picked it up. Then I drank the beer. mmm If you do place an order, I've been drinking "Mount Desert Islan Ginger" Ale. They have it in stock there. It costs about $7.88 per six pack. :-) --pete

Ok, recall now supports tabs! Works in Mozilla 1.4 RC1 --pete

awesome!

Pete, I have two questions: 1) Can this be installed under Linux with only user privileges into the home directory? 2) Can this be included into Mozilla directly? pi

*** Bug 208994 has been marked as a duplicate of this bug. ***

These would be useful not just in case of a Mozilla crash, but also in case of a system crash, power outage, or desire to manually save session info.

*** Bug 223635 has been marked as a duplicate of this bug. ***

I was going to add bug 193567 as a dependency here, then realised that it wasn't applicable. This bug seems to be about recovering *session history* after a crash - not about anything else (comment 43, w/r/t email message in the process of being composed, appears not to have been incorporated). So - tweaking summary to clarify the intent of this bug. If I'm wrong, and it's really about recovering everything in place prior to the crash, then the summary can be changed back - but other bugs (like bug 193567) should be added as dependencies also.

Oops, sorry - added dependency by mistake before changing my mind. <sigh> But I now notice that several of the other dependencies are not, after all, window/tab state specific either (they include form data and email mail/news composition). So - is this about recovering ALL lost data after all, or just session history? (If I go by the original summary it's just session history but it may have morphed.)

There's a Firebird plugin (SessionSaver): http://www.pikey.me.uk/mozilla/

Okay, no response so I'll have to assume that this bug is about recoverying ALL data since that's what the existing dependencies imply. Tweaking summary back again. Marking some more obvious dependencies.

Specially a mail loss is disturbing - is there anything available for thunderbird (aka Mozilla mail 1.6)?

Jason, this is not a profile corruption bug. That is bug 123929. This bug does not cover data loss that is incurred because a profile file got messed up or deleted in the event of a crash or hang. This bug covers user data that is not yet saved in the profile. Let's say you are typing in a form on a web site, and Mozilla crashes. If bug 156765 were fixed, the data you were typing might be saved. That would save me a few gray hairs. Another example. Let's say you are surfing around. You have 5 windows open and 36 tabs. Mozilla crashes. Assuming history.dat isn't corrupted by the crash (that corruption would be covered by other bug reports), you could painstakingly go through your entire history and figure out all the URIs that you had open. With a fix for bug 36810, however, the next time you opened Mozilla, you would get a message that said: "I see that you had 5 windows and 36 tabs open, but then Mozilla somehow stopped working. Would you like me to re-open those for you?" You say, yes, and bada bing, you've got your environment back. To fix these bugs, data applicable to the Mozilla user environment must be saved to files. This data is not currently being saved. Where would that data be saved? Probably in the profile. Thus, this is a meta bug that calls for more data, new data, to be saved in the profile. It is not calling for the data that is already in the profile to be better safeguarded. The better safeguarding of profile data is tracked by bug 123929.

> This bug covers user data that is not yet saved in the profile. Aha! This clarification is better late than never. <grin> However, the Summary here *does* still need to be tweaked to explicitly clarify what this bug is about. (Or else it will start morphing all over again into something you don't want.)

I think it might be a good idea to include the recall feature as a default in Mozilla and Mozilla Firebird as it would be very convenient to go back to where you were after a browser crash.

*** Bug 233919 has been marked as a duplicate of this bug. ***

The way Opera (and Galeon) handle it ["Recover", "Don't Recover", "Exit"] on booting up the program is really good. In addition, it would be great if you could have a "Recover some" button that was just a list of all the windows/tabs that were open with (ticked by default) checkboxes next to them. That way, if one of the pages is crashing the browser, you have the option to surgically excise it. Or maybe there's only a couple of key pages that you particularly want back. If it's possible to flag which one CAUSED the crash, that would be even better still, but I suspect that's a big ask.

*** Bug 254955 has been marked as a duplicate of this bug. ***

*** Bug 257685 has been marked as a duplicate of this bug. ***

*** Bug 261908 has been marked as a duplicate of this bug. ***

*** Bug 272074 has been marked as a duplicate of this bug. ***

The SessionSaver extension (mentioned in comment #68) recovers all browser state data (including open tabs and typed text). It supports both Firefox and SeaMonkey / Mozilla Suite. For more information about this extension see the mozillazine knowledgebase: http://kb.mozillazine.org/SessionSaver To download the latest version and to discuss bugs see the following thread: http://forums.mozillazine.org/viewtopic.php?t=47184 Prog.

See bug 328154 for the corresponding Firefox bug which is targeted at version 2.0. The code is based upon my "Crash Recovery" component available from http://sessionmanager.mozdev.org/crashrecovery/ (SeaMonkey compatible). Should anybody want to work on this, feel free to CC me to the relevant bugs.

Note that the "Crash Recovery" extension (http://sessionmanager.mozdev.org/crashrecovery/) will not install in SeaMonkey 2.0a1. If "Crash Recovery" extension will not be compatible with SeaMonkey 2.0, then this bug will become more urgent since there will be no work around. Thanks!

Won't SeaMonkey 2.0 have built-in Session Restore support?

Bug 36810 has a working patch, waiting for review. Session Restore will be included from some alpha, and definitely will be in final SeaMonkey 2.

Bug 36810 has been solved, which was the wanted-seamonkey2+ feature that basically covers this functionality. A tracker like this doesn't really fit for wanted+ as it's not crisp enough to say "this is exactly the feature we want to solve". What comment #71 describes has been solved now, but some of the dependencies here might not yet be included in the feature (e.g. Composer), so I resisted the temptation of marking this a dupe of bug 36810.

Helga Luise: This is a SeaMonkey bug. I doubt that "firefox-esr10" tracking flags are relevant. However, this bug was filed in 1999, before Firefox even existed, so other possibilities would be to move this bug to Core, or to create a "sister bug" (if there isn't one yet) in Firefox (and possibly Thunderbird).

> I doubt that "firefox-esr10" tracking flags are relevant. Right you are. Also tracking meta bugs doesn't make much sense.

What is latest status on this bug? Is it working ("WFM")? Is it not going to be fixed ("WONTFIX")? Thanks.