Session Manager 0.1 to 0.3.9+

[alta88]

thanks anonemoose, i must have missed that discussion.

i'll try the fix, although i suppose it will be obliterated on a reinstall/update.

or should xul caching be enabled? as above, i didn't see the pref in about:config.

nothing worse than timing problems in a multithreaded environment, always having to post and enqueue to get it right, at least that was the lingo in my day..

[AnonEmoose]

xul caching is enabled by default, so unless you have disabled it there's no pref in about:config. it's when it's disabled that I have a problem. This was fixed already (per zeniko's testing) but for some reason the fix doesn't work on my machine....

Anyways, I only brought it up as perhaps the workaround I employ (ie. increasing the 100 -> a larger number) might work to solve your issue (which might have to do with having so many extensions installed, causing the window to instantiate slowly --- then again i may be barking up the wrong tree completely, perhaps your issue is a completly different thing)

[dougeeebear]

I was just looking around in about:config and noticed a bunch of entries regarding SessionSaver.
I did have it installed at one time to check out.
So I looked in prefs.js and I discovered that all the saved sessions as well as the prefs were stored there (I'm talking about an individual massive pref for each saved session).
Needless to say, I cleaned those entries out.
Remind me to never install that again.

This is about as illogical an approach as AdBlock Plus storing its filters in prefs.js (that's going to change).

Anyway, what I'm getting at is I think zenico takes a more logical approach with Session Manager storing saved sessions in individual files in their own directory (which is what Opera does).

I'm hooked on Session Manager.. it's the best one going.

@zenico: if you decide to put it up on AMO, I'll definately give it five stars for performance as well as for your support.

[********]

...

I'm hooked on Session Manager.. it's the best one going.

@zenico: if you decide to put it up on AMO, I'll definately give it five stars for performance as well as for your support.

me too

superT + Session Manager =
all your tab browsing needs without the code bloat

[dougeeebear]

@zenico:
Is there a way I can make the Session Manager and Undo toolbar buttons act as single action dropdowns instead of dual action (popup/dropdown) buttons?
I don't think all users would want this behavior, but it would work better for me.
Tab Mix Plus 0.3 has a pref to choose between single/dual action buttons.
I was wondering if you might consider adding a pref like that for the Session and Undo toolbar buttons.

[old zeniko]

Preserving closed windows worked, but it worked too good

Technically, closed windows are not part of the session and are currently stored separately. In what circumstances do you expect them to be preserved? Whenever you don't clear everything away? That's what happens as of <a href="http://www.haslo.ch/zeniko/software/sessionmanager.xpi">version 0.3.4</a> (of course only, if you set the pref to preserve the list or after a crash).

ah i recall many pages back a restart bug - would getting rid of MTLI solve it?

No, you just shouldn't use MTLI's Restart option (and ironically neither "Restart Firefox"'s - use this work-around instead).

as for nglayout.debug.disable_xul_cache - i don't have the pref.

It turns out that this pref wasn't the cause, but merely tended to trigger a race condition more often. This should be fixed now.

On my machine I manually increase the value from '100' to '2100' in the crashrecovery.js (components folder)

Turns out that it wasn't Crash Recovery's fault, at all. When restoring multiple windows, Crash Recovery correctly waits for the windows to get created - however Session Manager didn't wait when manually restoring multi-window sessions. So far I just saw the symptom, but never the cause...

@zenico:
Is there a way I can make the Session Manager and Undo toolbar buttons act as single action dropdowns instead of dual action (popup/dropdown) buttons?
...
I was wondering if you might consider adding a pref like that for the Session and Undo toolbar buttons.

I don't like adding prefs for such subtleties but prefer to dictatorially decide for one way and stick to it. The solution to this problem (which exists since I've added the toolbar buttons) is to right-click the buttons (I've copied this behavior from the Back/Forward buttons, so you could even consider it standard).

BTW: The nick is "zeniko" with a k.

[dougeeebear]

BTW: The nick is "zeniko" with a k.

Typo, sorry.

[giksos]

hi guys!

I have a problem: the last tab doesn't get reloaded on session restore. It just stays blank and (untitled). I had the same problem with SessionSaver, that's why I switched to SessionManager. At first it was good (sadly I don't remember which version it was), but after upgrading to 0.3.4 the problem reappeared.
Do you have any idea, what could be wrong? It can't be completely the fault of SessionManager, because SessionSaver also had it (many people complained about it there). It must be something about Firefox itself, but I have no clue where to look for or what bug to submit.

If you can't help, where could I get old versions of SessionManager? They should work for me.

Cheers,
Misha

[old zeniko]

I have a problem: the last tab doesn't get reloaded on session restore. It just stays blank and (untitled).

Does this happen always or only occasionally? When automatically resuming or when manually restoring? Do you get any error messages in the JS console after startup? Does this also happen on a clean profile (i.e. no other extensions installed - if it doesn't: what extensions are you using)? Does it happen with any site loaded in the last tab or just for specific URLs? What Firefox version are you using?

In short: could you please elaborate the steps to reproduce this behavior? I've never seen this before and won't be able to do anything against it without more information.

As for older versions: I unfortunately have the bad habit to discard all older version (except for the occasional backup). You can get version 0.3.3 at the Extensions Mirror.

[giksos]

Some investigation results: I tried the file firefox-1.5.0.1.tar.gz from the official site. It installs the configuration
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
with this configuration everything works fine.

Preiously (as I work on SuSE) I was using a SuSE rpm, which installed
Firefox 1.5.0 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060103 SUSE/1.5-5.1 Firefox/1.5.0.1)
which had the problem.

I will compare the two installations and try to find something that looks suspicious.

The problem itself is as follows:
- open the browser
- open several tabs, point them to any adresses
- close or kill the browser
- open the browser again
-> when restoring the tabs the last tab doesn't get restored and stays blank. The effect is always there.

I tried this after whiping out firefox, removing all configuration directories and installing firefox back. So other extensions shouldn't be to blame.

Cheers,
Misha

[old zeniko]

I can not reproduce this behavior - and apparently neither any of the other posters in this thread (or they would have cried out much earlier).

If I understand you correctly, you do not have the problem with the official 20060124 build. Should this be the case, please simply stick to that one.

Otherwise please confirm that you don't get any errors or warnings in the JS console with both javascript.options.strict and javascript.options.showInConsole set to true (you'll have to restart for the full effect - you might want to install Console² for being able to copy all entries at once).

[feline_dracoform]

first up i am very impressed with session manager so far. i have swapped over from Session Saver, since SS developed the nasty habit of failing to save (or restore, i never worked out which) my sessions about 1/3 to 1/2 of the time *yuk*

so far i have only had this problem once with SM, once at home and once at work.

on my work machine (this was a couple of days ago, so from memory)
OS = winXP pro
using firefox 1.5.0.1

i upgraded from SM 0.2.x to 0.3.x via the firefox extensions dialog and then restarted firefox. upon restart no tabs were restored, despite me having the option to restore my previous session turned on. i went to the session saver menu (under tools) and selected my previous session, at which point it was restored. the tabs on that machine rarely change, they just get refreshed, so i cannot easily tell if there was a problem or not.

on my home machine i have just had a similar problem, about 10 minutes ago, so i can report while it is fresh in my memory.
OS = winXP pro
using firefox 1.5.0.1

i installed the extension image_toolbar-0.6.3-fx.xpi which opened the extensions dialog to tell me this had worked and that i needed to restart. while in there i saw that SM was now on 0.3.4 so i selected upgrade, i was on 0.2.x (probably 0.2.13.1 based on the xpi file i have on my usb stick) before the upgrade.

when i restarted firefox i was presented with a totally black brower window - there was the menu, toolbar, status bar, but no tabs, and just a big white expanse. after a couple more restarts i realised that the problem was no tabs were open, so no tab bar showing, and no page loaded. it is post midnight, so going to sleep, which did not help. but i need to post the details while they are fresh.

in the SM menu there are two previous sessions listed, neither work when selected - i.e. absolutely nothing happens. i have opened the folder and backed up these two files. this is a different behaviour to my work machine experience.

the list of closed tabs and closed windows has been blanked, i am not sure if this is intentional or not.

working theory - i recall you posting you had changed the file format to ini format for version 0.3, the previous format saved session is not being correctly loaded by the new builds.

is there any way for me to restore my lost sessions? i have opened the session file "_ Crashed Session (2006-03-07 23_45) _.session" in vim - this was created after the machine spontaneously rebooted yesterday *DOH* and should contain around 20 tabs. the file is 14 lines long, and contains basically no information. certainly there are no URL's visible in this file.

i am off to down grade SM to 0.2.13.1 to see if that restores anything. i have opened 3 tabs in one window with SM 0.3.4 and this session is being restored. however i rather want the previous session back if at all possible. i keep tabs open for things i have to finish doing, so accurate session management is both a killer feature for me, and vitally important that it work reliably.

hopefully this all makes sense.

[AnonEmoose]

as for nglayout.debug.disable_xul_cache - i don't have the pref.

It turns out that this pref wasn't the cause, but merely tended to trigger a race condition more often. This should be fixed now.

On my machine I manually increase the value from '100' to '2100' in the crashrecovery.js (components folder)

Turns out that it wasn't Crash Recovery's fault, at all. When restoring multiple windows, Crash Recovery correctly waits for the windows to get created - however Session Manager didn't wait when manually restoring multi-window sessions. So far I just saw the symptom, but never the cause...

Confirmed that xul caching issue is fixed with 0.3.4. nicely done.....

Bug Squashed !!

zeniko:
I can't believe how far Session Manger has come in a few short weeks.... It has been feature complete (for me) for about 2 of those weeks.... Absolutely excellent work (feature set, coding and of course your persistance) and to think that an innocent sentence

You seem to want to mis-use Crash Recovery as a session manager...

and http://forums.mozillazine.org/viewtopic ... 91#2047291 may have spurred your interest in to 'mis-use CrashRecovery'.... hehehe

[feline_dracoform]

update - the subject post did not make it onto the forum, which was slightly unhelpful. it was something like "session lost after upgrade from 0.2.x to 0.3.x"

as i half expected downgrading to 0.2.x did not help, so i am back on 0.3.4

i have backed up my current profile directory in case anything can be recovered from it, but i have tried opening all of the interesting / relevant looking files in vim and not found anything. it seems that the repeated close and open cycles as i tried to work out what was going on removed / over wrote the information i was hoping to recover.

i should probably have been more careful doing the upgrade *sigh*

[alta88]

ah i recall many pages back a restart bug - would getting rid of MTLI solve it?

No, you just shouldn't use MTLI's Restart option (and ironically neither "Restart Firefox"'s - use this work-around instead).

wow, that's a bit..esoteric. i'd rather not map a key for this. can i alter something to make the Restart button run this macro, something onCommand like? does mrtech intend to fix this?

i just came across another wierdness. i accidentally saved window B as window A, immediately realized the mistake and saved it as B, then went to the other desktop and saved A again as A. well, after closing B and reopening it, one blank window came up + two A windows. several closes and restarts later, each with seemingly different behavior of B opening, it finally worked again. do you not do a complete rewrite of a session file on explicit save? 0.3.3.