[Ext] Session Manager 0.4 to 0.4.3Is anyone else using Session Manager and Trunk 3.0 builds successfully? I keep crashing a lot with ntdll.dll errors and possible others?
now it works with v0.4.0.8+ for the Problems:
- crash at startup - crash at restoring sessions with multiple windows i find out the bad extension: firebug dont work in combination with MAF or PageZoom [de] with the console logging tool i find out, that firebug goes into a endless error-loop because of a error in the firebug source. this endless loop only happens if: - SessionManager restore Sessions at startup - SessionManager restore sessions with multiple windows Testcases: FB - FireBug 0.3.2 MA - Mozilla Archive Format 0.6.3 PZ - PageZoom [de] 0.3.0 SM - SessionManager
Does this also happen on a clean profile? If so, please file bugs again the Trunk. Session Manager as a pure JS extension shouldn't be able to crash the browser at all. And the new SessionStore component is largely based on Crash Recovery and might thus exhibit similar issues when it's finally enabled.
Please notify Joe Hewitt (Firebug's author) about this issue. I prefer not to include hacks which only happen in very specific situations (and of course I'm convinced that I'm not doing anything irrecular ![]()
ntdll.dll bug already filed against trunk, I've added my talkbacks, I'm assuming it's an issue with the disk writes as ntdll.dll is a core component and recent fx changes, was just wondering if anyone else was seeing this. btw, this happens with both Session Manager and Crash Recovery, not with SessionSaver or other extensions, if it helps any.
Thanks for that info. I have the button titles displaying correctly, but both buttons execute this.remove(aSession). If I click on "Don't Delete", it still deletes the session. There must be something else I'm missing, but the references don't show anything else. I'm using the code from this page.
You don't have to tell me. Tell the devs over at Bugzilla. ![]() Are you actually able to reproduce the crashes on a clean profile? This could even be due to an incompatibility with another extension... (if it is, please bug them, not me ![]()
So you'll have to check for <code>confirmEx(...) == 0</code>. A note for nightly users: <a href="http://www.haslo.ch/zeniko/software/sessionmanager.xpi">Session Manager 0.4.1</a> disables the new SessionStore and replaces it with its own (Crash Recovery - of which SessionStore is a fork). I'll probably port core improvements from SessionStore back to Crash Recovery (however not the API), but don't expect Session Manager to work without Crash Recovery from me...
is it possible to edit the navigation toolbar buttons for us users? i would like to edit the buttons so they blend in better with firefox orginal theme. Or has someone already made alternative buttons?
Today's <a href="http://www.haslo.ch/zeniko/software/sessionmanager-dev.xpi">testing release</a> (0.4.1.4+) contains a basic protection against repeated crashing: potentially crashy pages are replaced with a warning page. Nothing perfect, but maybe even a better alternative than a dialog from which to deselect tabs (because you'll still have access to the tab's history). Comments?
@modellmakt: You can replace Session Manager's toolbar buttons through the same userChrome.css hackery which can be used to replace any button. Of course you'd need alternative images first... 1. need install help for the entry hack
"Add the following method to gSessionManager and call it then on the result of getSessionState in the save method" can you help me how to include this hack to the userchrome.js ? 2. include the entry hack to the core extension now after some hours i run into a slow phase if the crashrecovery.dat goes high to 220kb. with sessionmanager it is impossible to use selfrefreshing pages, because of the entry issue. i think other people have the same problem, and so it is better to include the entry hack as optional in the extension core. 3. Repost Data
the problem is: if the page is in restore process, then only the "repost data"-dialogbox is opened. there is no url in the adress-textbox. so you have to confirm a repost to a hidden resource. but you save the posting data in the crashrecovery.dat file as value at "postdata". so it would be better if there is a repost, then you make a confirmation (maybe in the restored window or direct after the start of the restore) with this informationbox:
If something like that dialog mockup is done, be sure to limit the length of the data displayed. Forum posts can be really long.
Also, I think the options should be something more like "Yes, repost the data", "No, open this page without reposting it", "No, open the last page in that tab" and maybe "No, open my home page" or a blank page. Also also, I think it might be useful to list the URL it's being posted from. Yes. but i think this repost data could be also go to a seperate extension, because the repost data is chrome-thing.
I've slightly modified how the crash warning works. Please test today's <a href="http://www.haslo.ch/zeniko/software/sessionmanager-dev.xpi">testing version</a> (0.4.1.5+) and comment on what you think about them.
The short version is: add <a href="data:text/javascript,gSessionManager.removeTabHistory%20%3D%20function(aState)%20%7B%0A%09return%20aState.replace(%2F%5Cn%5C%5BWindow(%5Cd%2B%5C.Tab%5Cd%2B)%5C%5D%5Cn%5B%5Cs%5CS%5D*%3F(%3F%3D%5Cn%5C%5BWindow(%3F!%5C1)%7C%24)%2Fg%2C%20function(%240%2C%20%241)%20%7B%0A%09%09var%20data%20%3D%20%240.split(%22%5Cn%5Cn%22)%3B%0A%09%09if%20(%2F%5Eindex%3D(%5Cd%2B)%2Fm.test(data%5B0%5D))%20%7B%0A%09%09%09var%20index%20%3D%20RegExp.%241%3B%0A%09%09%09data%5B0%5D%20%3D%20data%5B0%5D.replace(%2F%5E(index%3D)%5Cd%2B%2Fm%2C%20%22%2411%22)%3B%0A%09%09%09return%20data.filter(function(aEntry%2C%20aIx)%20%7B%0A%09%09%09%09var%20header%20%3D%20%22%5BWindow%22%20%2B%20%241%20%2B%20%22.Entry%22%20%2B%20index%3B%0A%09%09%09%09return%20aIx%20%3D%3D%200%20%7C%7C%20aEntry.indexOf(header%20%2B%20%22%5D%22)%20%3D%3D%200%20%7C%7C%20aEntry.indexOf(header%20%2B%20%22.%22)%20%3D%3D%200%3B%0A%09%09%09%7D).join(%22%5Cn%5Cn%22).replace(%2F%5E(%5C%5BWindow%5Cd%2B%5C.Tab%5Cd%2B%5C.Entry)%5Cd%2B%2Fgm%2C%20%22%2411%22)%3B%0A%09%09%7D%0A%09%09return%20%240%3B%0A%09%7D)%3B%0A%7D%3B%0A%0Aeval(%22gSessionManager.save%20%3D%20%22%20%2B%20gSessionManager.save.toString().replace(%2Fthis%5C.getSessionState%5C(.*%3F%5C)%2F%2C%20%22this.removeTabHistory(%24%26)%22))%3B%0A">these lines</a> to your userChrome.js. Note however that this will only work for manually saved sessions. The easiest way of getting this globally would be to edit crashrecovery.js (in the extension's components subdirectory) and change the line
to
(this will save at most three history entries - the current one and the one prior and the one after that). To just get one entry, the line would have to read
(and by now you should get the idea).
This won't happen while I develop this extension. I doubt that this would be a much used option. Note that self-refreshing pages aren't supposed to add new entries to the tab's history at every refresh. If they do, consider them broken.
As I already mentioned: there's currently nothing I can do about this - no need to argue. Return to Extension/Theme Releases Who is onlineUsers browsing this forum: Bing [Bot] and 1 guest |
![]() |