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

NEW
Unassigned

Status

SeaMonkey
UI Design
--
enhancement
18 years ago
a month ago

People

(Reporter: CodeMachine, Unassigned, NeedInfo)

Tracking

(Depends on: 3 bugs, {meta})

Dependency tree / graph
Bug Flags:
wanted-seamonkey2.0 -

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
Summary: Crash Recovery → [RFE] Crash Recovery
Target Milestone: M14

Comment 1

18 years ago
Move to M20.

Comment 2

18 years ago
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".
(Reporter)

Comment 3

18 years ago
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.

Comment 4

18 years ago
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash

Comment 5

18 years ago
this doesn't really need the "crash" keyword does it.  Removing crash keyword.
Keywords: crash

Comment 6

17 years ago
Adding crash keyword.
Keywords: crash

Comment 7

17 years ago
Move to "Future" milestone.
Target Milestone: M20 → Future

Comment 8

17 years ago
not sure why the crash kw was readded to this. it's not a crasher
Keywords: crash

Comment 9

17 years ago
Adding crash to keyword field.
Keywords: crash

Comment 10

17 years ago
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) :-)
Keywords: crash
Summary: [RFE] Crash Recovery → [RFE] Recovery from times that Mozilla is shut down due to an error and needs to be restarted

Comment 11

17 years ago
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)
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]

Comment 12

17 years ago
Adding crash keyword.
Keywords: crash

Comment 13

17 years ago
t h i s   i s   n o t   a   c r a s h
Keywords: crash

Comment 14

17 years ago
Adding crash keyword
Keywords: crash

Comment 15

17 years ago
<sigh> not a crash
Keywords: crash
Summary: [RFE] Crash Recovery → [RFE] C r a s h Recovery

Comment 16

17 years ago
thanks...bulk move...oops...
Whiteboard: [NotACrash,Jan]

Comment 17

17 years ago
use the mozdev.org url instead
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy

Comment 19

17 years ago
nav triage team:

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

Updated

17 years ago
QA Contact: don → sairuh

Comment 20

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

Comment 21

17 years ago
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.)

Comment 22

17 years ago
Whee, mid-air collisions are fun.

Comment 23

17 years ago
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

Comment 24

17 years ago
kicking out to nobody
Assignee: vishy → nobody
Keywords: helpwanted

Comment 25

16 years ago
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.

Comment 26

16 years ago
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

Comment 27

16 years ago
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 → ---

Comment 28

16 years ago
*** Bug 105382 has been marked as a duplicate of this bug. ***
*** Bug 107543 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
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?)

Comment 31

16 years ago
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.

Updated

15 years ago
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

Comment 36

15 years ago
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.

Comment 38

15 years ago
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.

Comment 39

15 years ago
*** Bug 166233 has been marked as a duplicate of this bug. ***
*** Bug 175184 has been marked as a duplicate of this bug. ***

Comment 41

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

Comment 42

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

Comment 43

15 years ago
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.

Comment 44

15 years ago
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

Comment 45

15 years ago
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. ***

Comment 47

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

Updated

15 years ago
Keywords: nsbeta1

Comment 48

14 years ago
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

Updated

14 years ago
Status: NEW → ASSIGNED
Depends on: 93789

Updated

14 years ago
Keywords: helpwanted, nsenterprise

Updated

14 years ago
Depends on: 16360

Updated

14 years ago
Depends on: 16359

Updated

14 years ago
Priority: P3 → --

Comment 49

14 years ago
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. ***

Comment 51

14 years ago
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.

Comment 52

14 years ago
> 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

Comment 53

14 years ago
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!

Comment 55

14 years ago
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)

Comment 56

14 years ago
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

Comment 57

14 years ago
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 

Comment 58

14 years ago
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)

Comment 59

14 years ago
> 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

Comment 60

14 years ago
Ok, recall now supports tabs!

Works in Mozilla 1.4 RC1

--pete
awesome!

Comment 62

14 years ago
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. ***

Comment 64

14 years ago
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.

Comment 65

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

Comment 66

14 years ago
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

Comment 67

14 years ago
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

Comment 68

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

Comment 69

14 years ago
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.
Summary: Crash Recovery (of websites visited, window / tab state) tracking bug → Crash Recovery (of all lost data) tracking bug

Comment 70

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

Updated

14 years ago
Depends on: 221797

Updated

14 years ago
Depends on: 174932

Comment 71

14 years ago
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)

Updated

14 years ago
Summary: Crash Recovery tracking bug (non-profile data) → Crash Recovery tracking bug

Comment 72

14 years ago
> 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.

Comment 73

14 years ago
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. ***

Comment 75

13 years ago
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.

Updated

13 years ago
Depends on: 131871

Updated

13 years ago
Depends on: 237647

Updated

13 years ago
No longer depends on: 156765

Comment 76

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

Comment 77

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

Comment 78

13 years ago
*** 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. ***

Updated

13 years ago
No longer depends on: 174932

Comment 80

12 years ago
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

Comment 81

11 years ago
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?

Comment 84

9 years ago
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.

Updated

9 years ago
Flags: wanted-seamonkey2?
Assignee: jag → nobody

Comment 85

8 years ago
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-

Updated

5 years ago
status-firefox-esr10: --- → ?
tracking-firefox-esr10: --- → ?
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).

Comment 87

5 years ago
> 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: ? → ---

Comment 88

a month ago
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)
You need to log in before you can comment on or make changes to this bug.