[Ext] Crash Recovery 0.6.10 [discontinued]

Talk about add-ons and extension development.
Locked
User avatar
satyr
Posts: 312
Joined: July 13th, 2004, 2:00 pm
Location: Ljubljana, Slovenia, Europe
Contact:

Post by satyr »

zeniko wrote:Cache Fixer is still included. It is however not as reliable as I'd like it to be (just better than nothing).


Well, my post is not related directly to Crash Recovery extension ...


But since it say on the Cache Fixer extension's page (download it or install it here), that it's functionality is built-in into the Crash Recovery extension, I will ask this question here: does anyone know, is Cache Fixer supposed to work with Firefox 1.5.0.3 ?? And if it isn't, does anyone know if it will be updated anytime soon (if at all) ??


You see, as you al probably know, this particular extension is totally awesome (and indispensable to me; I still use a dial-up connection to the Internet), since it actually fixes the "cache vanishing bug" as I call it: 105843; for more info see this thread on Extensionsmirror. Basically, it drops a "dirty flag" on every application's startup, so that the browser always "sees" the cache as uncorrupted/clean, even if the cache was left in a dirty/unexpected state on the process exiting)


P.S. -- But for even more details on how I've discovered this bug myself, which things I tried before to solve the problem etc., please see the About the cache-files and closing the "firefox.exe" process with "EndTask" method thread that I opened on Ars Technica or the Cache and closing the Firefox with EndTask method thread here at MozillaZine where it was first suggested to me to use the Cache Fixer extension.


shirker
If you want to, please check out my site: tadej-ivan.50webs.com, and enjoy reading my computing-related discoveries, hints, principles, and rules.
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old zeniko »

satyr wrote:Well, my post is not related directly to Crash Recovery extension ...

In that case, please don't post in this thread. Rather start a new thread in the extensions forum. Of course, you could always install Crash Recovery instead (which is compatible with Firefox 1.5.0.*)...
User avatar
mrtech
Posts: 2007
Joined: May 15th, 2003, 7:46 am
Location: New York
Contact:

Post by mrtech »

zeniko wrote:That's MTLI taking advantage of Crash Recovery. If you don't like it, just set the pref local_install.enableSessionManagerResume to false (although I can't imagine why you wouldn't want it ;)).

thanks for reminding me I've just updated the Hacks page on my site:
http://www.mrtech.com/extensions/local_ ... hacks.html
mel reyes • mrtech.com • BlogPlaxoLinkedInTwitter
Support mrtech.com get our toolbar
AnonEmoose
Posts: 2031
Joined: February 6th, 2004, 11:59 am

Post by AnonEmoose »

Related to the crashrecovery.js ...

Session Manager 0.4.1.7+ seems to cause many crashes on nightlies (i've tested over the past week or so), seemingly from the fix you put in crashrecovery.js due to the thread stuff.

reverting to an older version of old crashrecovery.js (without the thread fix) and crashes stop (but still has error Henrik posted at http://bugzilla.mozdev.org/show_bug.cgi?id=14289 )

this might be unrelated but a 'load' event seems to be triggered some onmouseovers of the tabbar ( focused tab's close button ??)

If you need more details, I can provide more on Monday.....
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old zeniko »

AnonEmoose wrote:Session Manager 0.4.1.7+ seems to cause many crashes on nightlies (i've tested over the past week or so), seemingly from the fix you put in crashrecovery.js due to the thread stuff.

Crash Recovery shouldn't be able to crash Firefox, because it's implemented in pure JavaScript. If you do get crashes, that's due to critical errors introduced in Minefield - which isn't really thought for actual consumption and which due to its more-than-a-little-bit-shaky state I don't have any motivation to test for. If you insist on using trunk nightlies, you might want to try replacing the line

Code: Select all

if (aMainThread)

with

Code: Select all

if (true)

which should disable all threading and might cause the bugs to be hidden again.

AnonEmoose wrote:this might be unrelated but a 'load' event seems to be triggered some onmouseovers of the tabbar ( focused tab's close button ??)

How does this "load" event manifest itself? And what do you think it's got to do with Crash Recovery?

On a related note: should the new SessionStore service really ship with Firefox 2.0, Crash Recovery will be discontinued, since it's almost the same code. SeaMonkey users should still be able to use the current version - but they're recommended to help writing a patch for bug 19454 (e.g. on base of Crash Recovery/SessionStore).
AnonEmoose
Posts: 2031
Joined: February 6th, 2004, 11:59 am

Post by AnonEmoose »

zeniko wrote:Crash Recovery shouldn't be able to crash Firefox, because it's implemented in pure JavaScript. If you do get crashes, that's due to critical errors introduced in Minefield - which isn't really thought for actual consumption......


Of course I don't expect you to support Minefield in it's current state, it more of an FYI/exploratory post...

Entirely possible it's a Minefield issue, but thought I'd post since the thread code seemed to be the only difference..... I did wait to see if updates to Minefield would help and when they didn't figured I'd post & see if anyone else has same issue....

I will try to provide addtional/expanded information (including the talkback report) on Monday (work machine).

load event perhaps is triggering a save of the session (thread creation/destruction) more than neccesary ??
AnonEmoose
Posts: 2031
Joined: February 6th, 2004, 11:59 am

Post by AnonEmoose »

It's Monday !!

So here are some talkback incidents generated soon after using the 5-18-06 version of crashrecovery.js with Minefield. Reverting to the one in SM 0.4.1.1 and no more crashes....

http://talkback-public.mozilla.org/sear ... d=19535204
http://talkback-public.mozilla.org/sear ... d=19535139
http://talkback-public.mozilla.org/sear ... d=19535039

Incidentally in Bon Echo there is not an issue...

Again this is more an FYI than requesting support as the issue obviously may be with Minefield
User avatar
Mishail
Posts: 8
Joined: November 10th, 2005, 12:55 am
Contact:

Post by Mishail »

Crash Recovery will be included in Firefox 2.0 (see the plan and the relevant bug 328159).


Could someone confirm that restore cache after crash (to fix 105843) functionality of CrashRecovery will be included in Firefox 2.0? Thnx
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old zeniko »

Mishail wrote:Could someone confirm that restore cache after crash (to fix 105843) functionality of CrashRecovery will be included in Firefox 2.0?

It's not. Use Cache Fixer as a temporary work-around until the bug you mention finally gets fixed.
User avatar
Mishail
Posts: 8
Joined: November 10th, 2005, 12:55 am
Contact:

Post by Mishail »

zeniko wrote:It's not.

Thanks a lot for promptly response.
SERENDIPITI
Posts: 25
Joined: January 20th, 2006, 10:34 am

Post by SERENDIPITI »

can cache fixer me made compatible with FX 2??..this is gr8 extension especially for people like me who are on dialup.
tmetro
Posts: 38
Joined: October 8th, 2004, 1:49 pm

Post by tmetro »

zeniko wrote:If you want to make sure that it works, go to Edit -> Preferences -> Navigator and select for "Display on Navigator Startup" "Last Page Visited". Restarting SeaMonkey with more than one tab open should then restore all tabs. ... And the ultimate test is of course: kill SeaMonkey's process, restart it and watch what's being recovered...


This implies that killing the process and restarting should automatically restore the prior session without needing to change the preferences indicated above.

In my experience, after installing Crash Recovery 0.6.10 on Mozilla 1.7.x and SeaMonkey 1.0.6, a restart after a killed process did not restore the previous session. However, Crash Recovery was apparently installed and working, as it was maintaining a crashrecovery.dat.

I found that after I adjusted the preferences as indicated above, it started to work (at least with SeaMonkey).

I'd recommend adding a note to the Crash Recovery page about this, seeing as Crash Recovery is still one of the better solutions to crash recovery on Mozilla/SeaMonkey and will probably see continued use.

-Tom
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old zeniko »

tmetro wrote:In my experience, after installing Crash Recovery 0.6.10 on Mozilla 1.7.x and SeaMonkey 1.0.6, a restart after a killed process did not restore the previous session.

In my experience, a crashed SeaMonkey 1.0 is restored without a fuss.

Note that there's no dialog or anything when the session is restored - you should just get your opened windows back (the dialog is only shown when the crash repeats itself). Also note that Crash Recovery doesn't save anything during the first 5 to 10 seconds - so don't kill the process too quickly. Finally make sure to test on a clean profile as well... and to report errors, should you see any in the JavaScript/Error Console.
tmetro
Posts: 38
Joined: October 8th, 2004, 1:49 pm

Post by tmetro »

zeniko wrote:Note that there's no dialog or anything when the session is restored...

Right, as expected. Your documentation was clear on that point.


zeniko wrote:...you should just get your opened windows back...

Just a single blank window on restart.


zeniko wrote:Also note that Crash Recovery doesn't save anything during the first 5 to 10 seconds - so don't kill the process too quickly.

Yup, I was aware of that. (As a long time user of Session Manager on Firefox.) I opened several tabs, waited in excess of 10 seconds, then killed the process. I repeated that several times after installing the extension with the same results.


zeniko wrote:...and to report errors, should you see any in the JavaScript/Error Console.

I checked the console at several points, and it was clean.


zeniko wrote:Finally make sure to test on a clean profile as well...

This I did not try. I used a profile that was created a few releases of Mozilla back. However, given the rather minimalists Mozilla setup, with no extensions other than Venkman and Crash Recovery, I'm not sure the profile would be to blame. I suppose some odd user preference might be throwing it off, though to my recollection I haven't altered any preferences beyond the GUI accessible ones. (I did play around with crashrecovery.sessionsaver, as suggested on the first page of this thread, but it seemed to have no affect either way, and I only experimented with it after determining that Crash Recovery wasn't working.)

If you're interested in fixing this bug, and the behavior isn't reproducible elsewhere, then I'll try a new profile. Will that be an adequate test, or will I need a clean install of SeaMonkey? (My understanding is that extensions can't easily be uninstalled from SeaMonkey...though I could manually delete the files.) If I reuse my existing install, should the extension be reinstalled after the new profile is created? Are there any preferences that might affect Crash Recovery's ability to restore on restart?

Thanks for the follow-up.

-Tom
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old zeniko »

tmetro wrote:I did play around with crashrecovery.sessionsaver, as suggested on the first page of this thread

That pref is from the good ol' 0.3/0.4 days and is no longer recognized as Crash Recovery has since been rewritten from scratch.
tmetro wrote:If you're interested in fixing this bug

Since the extension has been discontinued and there is a work-around available, my interest in this issue is quite limited, I'm afraid.
tmetro wrote:will I need a clean install of SeaMonkey?

The issue with SeaMonkey is that it's absolutely ungrateful to work with -- especially in comparison with Firefox. You could indeed try a clean profile first, but if that doesn't cut it, a clean installation of SeaMonkey itself might still make a difference (since Crash Recovery itself isn't installed into the profile but SeaMonkey's own installation folder).

Before you do any of this, make sure that you're correctly killing SeaMonkey in the first place, though. Some ways of exiting an application still cause a clean shut-down instead of an instant crash (e.g. on Windows, you'll have to use the Processes tab of the Task Manager; using Exit Task in the Applications pane won't work)...

BTW: I've just now made the test with the latest SeaMonkey 1.1 nightly -- and Crash Recovery still works as expected (except for at least one minor bug: about:config's textbox is no longer restored).
Locked