Open Bug 19454 Opened 25 years ago Updated 2 months ago

[meta] Crash Recovery (of all temporary browser state data) tracking bug

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: CodeMachine, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: meta, Whiteboard: Read comment #71 before posting | Workaround in comment #80)

Attachments

(1 obsolete file) 

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.
Summary: Crash Recovery → [RFE] Crash Recovery
Target Milestone: M14
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.
Keywords: crash
this doesn't really need the "crash" keyword does it.  Removing crash keyword.
Keywords: crash
Adding crash keyword.
Keywords: crash
Move to "Future" milestone.
Target Milestone: M20 → Future
not sure why the crash kw was readded to this. it's not a crasher
Keywords: crash
Adding crash to keyword field.
Keywords: crash
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) :-)
URL: http://www.mozillazine.org/chromezone...
Keywords: crash
Summary: [RFE] Crash Recovery → [RFE] Recovery from times that Mozilla is shut down due to an error and needs to be restarted
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)
URL: http://www.mozillazine.org/chromezone... → http://www.alphanumerica.com/projects...
Summary: [RFE] Recovery from times that Mozilla is shut down due to an error and needs to be restarted → [RFE] Crash Recovery
Whiteboard: [NotACrash,Jan]
Adding crash keyword.
Keywords: crash
t h i s   i s   n o t   a   c r a s h
Keywords: crash
Adding crash keyword
Keywords: crash
<sigh> not a crash
Keywords: crash
Summary: [RFE] Crash Recovery → [RFE] C r a s h Recovery
thanks...bulk move...oops...
Whiteboard: [NotACrash,Jan]
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
nav triage team:

Would be nice, but go use total recall. ;-) Marking nsbeta1-
Keywords: nsbeta1-
QA Contact: don → sairuh
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
Assignee: vishy → 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
URL: http://aphrodite.mozdev.org/total_rec... → http://recall.mozdev.org/
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).]
Summary: [RFE] C r a s h Recovery → Crash Recovery
Target Milestone: Future → ---
*** 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.
Depends on: 36810
*** 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. ***
Blocks: 156765
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?
Keywords: qawanted
QA Contact: sairuh → nobody
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. ***
Keywords: nsbeta1
Taking. This is really a tracking bug. The three main bugs are bug 36810, bug
156765, and bug 63094.
Assignee: nobody → xah
No longer blocks: 156765
Depends on: 63094, 156765
Keywords: nsbeta1, qawanted → meta, nsenterprise
Summary: Crash Recovery → Crash Recovery tracking bug
Status: NEW → ASSIGNED
Depends on: 93789
Keywords: helpwanted, nsenterprise
Depends on: 16360
Depends on: 16359
Priority: P3 → --
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.
URL: http://recall.mozdev.org/
*** 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.
Depends on: 193567
Summary: Crash Recovery tracking bug → Crash Recovery (of websites visited, window / tab state) tracking bug
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.)
No longer depends on: 193567
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.
Depends on: 22689, 63292, 114824, 131105, 158258, 193567, 193749, 205120
Summary: Crash Recovery (of websites visited, window / tab state) tracking bug → Crash Recovery (of all lost data) tracking bug
Specially a mail loss is disturbing - is there anything available for
thunderbird (aka Mozilla mail 1.6)?
Depends on: 221797
Depends on: 174932
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.
No longer depends on: 22689, 63292, 114824, 131105, 193567, 193749, 205120, 221797
Summary: Crash Recovery (of all lost data) tracking bug → Crash Recovery tracking bug (non-profile data)
Summary: Crash Recovery tracking bug (non-profile data) → Crash Recovery tracking bug
> 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.)
Summary: Crash Recovery tracking bug → Crash Recovery (of all temporary browser state data) tracking bug
Whiteboard: Read comment #71 before posting.
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.
Depends on: 131871
Depends on: failsafe
No longer depends on: 156765
*** 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. ***
Product: Core → Mozilla Application Suite
*** Bug 272074 has been marked as a duplicate of this bug. ***
No longer depends on: 174932
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.
Whiteboard: Read comment #71 before posting. → Read comment #71 before posting | Workaround in comment #80
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.
Assignee: contact9 → jag
Status: ASSIGNED → NEW
QA Contact: nobody
QA Contact: ui-design
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.
Flags: wanted-seamonkey2?
Assignee: jag → nobody
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.
Flags: wanted-seamonkey2? → wanted-seamonkey2-
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.
status-firefox-esr10: ? → ---
tracking-firefox-esr10: ? → ---
What is latest status on this bug? Is it working ("WFM")? Is it not going to be fixed ("WONTFIX")?

Thanks.
Flags: needinfo?(matty_is_a_geek)
Flags: needinfo?(matty_is_a_geek)
Summary: Crash Recovery (of all temporary browser state data) tracking bug → [meta] Crash Recovery (of all temporary browser state data) tracking bug
Attachment #9386775 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: