With the new tabbed interface (bug 218999 and see attachment 341994 [details] [diff] [review] from bug 402365) we'll have a tabbed interface enabled in Thunderbird. With our new tabs our users deserve to have their tab states saved on shutdown or crash through session restore. There already exists bug 408338 about Thunderbird having session restore and bug 449967 about generalizing the toolkit session restore this bug is specifically about implementing tab session restore. Each tab opened in Thunderbird will be viewing a search result, calendar, tasks, or possibly address book (see bug 457270). When a user shuts down Thunderbird we need to save the position and state of each of these tabs. In Firefox when you run the browser after saving your session it asks you in a dialog before starting if you want to restore the session or start a new one. In Thunderbird we are going to do this a bit better than that. On start up Thunderbird should open normally with one extra tab in focus, a session restore tab. In the session restore tab we can list the various tabs a person had open in a grid layout. Each item in the grid can be opened individually as well as having an option listed above all tabs to restore the entire session. This session restore tab can remain around until the user selects ( Restore Entire Session ) or closes the tab manually. When we restore a tab Thunderbird should attempt to bring it back to the exact state it was previously, including focus and scroll positions. Obviously in mail, like the web, sometimes what a person was looking at before no longer exists (at least in the same place). When the tab cannot be restored exactly as it was Thunderbird can do it's best and simply rerun the tab search command.

(In reply to comment #0) > bug 449967 about generalizing the toolkit session restore Sure, lets see how generalizable Session Restore really is. This probably won't make Toolkit 1.9.1 but it'd be nice to implement Thunderbird's Session Restore in such a general way that the same format can be used for Toolkit 1.9.2 (and Firefox 3.2) as a consequence. > In Firefox when you run the browser after saving your session it asks you in a > dialog before starting if you want to restore the session or start a new one. Actually, you see that prompt only after crashes - and it's on its way out as well (see bug 448976 comment #18 for our plans for Shiretoko)...

This isn't a final mockup yet, only intended to convey the idea of a session restore tab. I need to finalize the display of the tabs in the grid and some text for the buttons at the top. This tab could possibly be used for crashes ( like in bug 448976 comment #18 ), however I think Alex is on the right track using a different set of rules for restoring the session after a crash. Mainly this session restore tab is to allow Thunderbird to restore itself quickly (not loading up all the old tabs on restore) and give the user the option of bringing all the tabs back immediately or at their convenience. Also by giving a visible option of which tabs to open a user can selectively restore part of their session as needed. Some interesting interaction issues start to arise with this tab. If a person starts Thunderbird (quickly just to check their mail) and doesn't restore their old tabs, then shuts down again. Do we keep the old list of tabs in the session restore? I would think we do until they close the tab... Needs some more thought though.

Please consider providing a way to choose a set of default tabs (or a default saved session) that we can always automatically load when we start Thunderbird (without needing to see any session-restore tab or dialog).

Misak has been working on SeaMonkey session restore and so knows the code used on the browser side (like in Firefox) quite well. I hope we can build on that knowledge to get the feature into mailnews, including Thunderbird.

Sounds like a fine idea. Welcome, Misak.

Here's an improved mockup from the previous. Using a similar Firefox style for the borders and dialog. Each tab listed is a link that opens the tab (in the background w/ middle click or accel-click). The ( Restore Previous Tabs ) button opens all old tabs and closes the tab restore tab. The [ Forget Previous Tabs ] link closes the tab and removes the previous tabs from the session history, just like closing the tab would do. I tried adding in an "Always" checkbox for restoring with out asking. It's not quite right yet on a number of levels so I'm not too sure about including that initially.

Not sure who is going to handle this, but I'd like to see this make the b2 release. We have two pieces to complete. 1) Session restore backend code to save tab session information : Misak? :) 2) Session restore interface, how are we going to present our session restore to the users : ??

I have read a few comments, suggestions and issues related to tabs, but no mention of how to best use tabs in TB 3. This is only my '2 cents', but after using Eudora for more than 10 years I'm finding it hard to leave it for several reasons but one in particular. I operate a business. As such there are many inbound messages with which to deal. Some take days to complete tasks. So, when I receive a message into one of literally hundreds of mail folders, I 'tag' the message "and" have the ability to have unlimited folders open simultaneously - each in its own window/tab that is located near the status bar. Each time I open Eudora the folders that were left open appear as I had left them. The Eudora folder/tab is similar to the TB tabs. However, the tabs close when TB closes. I need to remember which tasks on which I was working or messages I need to address. If the tabs stay open until manually closed, even after closing TB and opening again, it makes my life easier than trying to find the messages (in the hundreds of folders and thousands of saved messages) in order to address those I've tagged as "HOT" or "TO DO". I hope the issue can be resolved so that when the final TB version is released I won't have to 'hunt' for important/tagged messages. I'd hate to have to return to Eudora...it's got it's bugs too.

I couldn't agree with Tom more. I often leave message open between sessions that have not been dealt with yet. That way when I re-open Eudora, the message is still there, open, in front of me reminding me to take care of it. I also use labels to identify certain types of messages, but I need to be able to leave messages open that still need to be addressed. I also use this feature on creating new messages and replying to messages. Sometimes, I do not have all the necessary information or time to properly reply to a message. I will begin the message and later that day or the next morning, open Eudora and my message is still there waiting for me to finish composing it. This ability is invaluable to me and the single biggest reason that I can not switch to TB. BTW, What happened? The first release was actually labeled as Eudora beta 8. Now it seems like Mozilla is trying to distance it's self from Eudora by no longer using the name. I thought the whole idea was to redo Eudora to start out with. I guess that goal has been lost somehow. :(

Thunderbird 3.0 and Eudora 8.0 are two separate products, although much of the code between them is shared. Likewise, there are two different teams of developers working on Thunderbird vs. Eudora, but since the source code is shared so is the development to an extent. See <https://wiki.mozilla.org/Penelope> for more details on the purpose of Eudora/Penelope. Eudora 8.0 betas do have the ability to restore tabs (and top-level windows as well) on startup. You can get the latest beta from <https://wiki.mozilla.org/Eudora_Releases>.

Any progress on the implementation of that enhancement? I really like it to work with tabs in Thunderbird but this issue is data loss for me because I have to open all needed tabs during each restart. Having multiple tabs in our feature list for Thunderbird 3 we should also do this. Any chance to get it into 3.0?

I too would like to see this. Back when we discussed where to place the switching buttons for calendar/task mode, one argument was that at some point there will be session restore, so the user will not so often need the buttons, which are quite small at the moment.

I have implemented this as part of my message pane fix on bug 498106. Which is to say, when you close the 3pane, any tab implementing the right method gets persisted. The tab will get restored when the 3pane next opens. I have not implemented, and am not planning to implement the proposed UI due to time restrictions. However, I must admit I'm not sure why we would want to introduce a UI affordance if we can just restore the tabs in the first place. My one concern about always restoring tabs would be that attempting to restore the tabs crashes thunderbird or otherwise makes it unusable (swap death, for one). I have attempted to mitigate a worst-case variant of the former by nuking the file we save the state to before we open the tabs. That way, if things go horribly wrong, next time we start we won't open it again. A potential mitigation for both cases is to not restore tabs when we are operating in "safe mode". Unfortunately, I have no idea at this instant how to detect safe mode, and am going to "lazybug" this for now...

Is this implemented through a similar mechanism as Firefox' session restore, or have you re-invented the wheel there?

(In reply to comment #18) > Is this implemented through a similar mechanism as Firefox' session restore, or > have you re-invented the wheel there? I investigated Firefox' session restore implementation and determined that: 1) There is little synergy in our use cases or implementation. Its tabs are homogeneous content tabs characterized by a location, history, and state associated with the content. This is well-suited to consolidated logic that knows how to directly restore each tab. Our tabs are heterogeneous implementations that, as implemented, are not easily characterized by an external actor without the help of the specific tab type implementation. 2) Its implementation appears to be legacy-influenced; I speak primarily of nsISessionStore, whose IDL file is actually longer than my implementation. If we benefited from the existing interface, I wouldn't have a problem, but there are only really 2 tab methods aligned with a "webby" use-case, setTabState/getTabState, and you still have to JSON stringify the object yourself in that case, so the interface isn't helping out much there. To make it clear, my ideal is the "jetpack"/webby idiom, which means populating an object and consuming an object of ones own creation, not having to write many lines of code to use helper functions that accomplish the same thing. 3) There's no easy way to re-use their implementation short of cut-paste-modify. Given the size of their implementation (sessionstore.js is 2900 lines), this is going to lead to a bad maintenance situation. We would basically have to fork it. Having said that, I think there are parts of their implementation that we would probably want to crib: 1) Window state restoration, namely the XUL properties persistence. I have currently punted on dealing with having multiple windows. We will need to implement our own service-y type of thing to handle a more global restoration, and there's no need to write that code from scratch. 2) Content tab restoration, if we want this in core. Obviously, Firefox knows how to do persist browser-type tabs, and I would not be surprised if there were many lessons baked into that code. I presume that your concerns stem from how this would impact SeaMonkey and its ability to persist/restore tabmail tabs. If MailNews tabs are still segregated in their own window, then you will be happy to know that tabmail's persistTabs/restoreTabs implementation is independent from any deeper session implementation and will happily take and return a JSON-serializable object. If SeaMonkey supports heterogeneous browser and mail tabs in the same window, then your session restore code will probably want to directly call persistTab/restoreTab on the tab/tab mode in question.

A patch is up on bug 498106 that provides tab persistence for folder and message tabs. Feel free to check out the implementation.

(In reply to comment #19) > I presume that your concerns stem from how this would impact SeaMonkey and its > ability to persist/restore tabmail tabs. Correct, as we have ported Firefox' session restore to the browser part of SeaMonkey, it would be nice to be able to restore mail tabs and windows as well. > If MailNews tabs are still segregated > in their own window, then you will be happy to know that tabmail's > persistTabs/restoreTabs implementation is independent from any deeper session > implementation and will happily take and return a JSON-serializable object. Sounds good, so it sounds like there is a good possibility to integrate the two solutions with each other. For now, mail tabs will be confined to different windows than browser tabs, even though our initial <tabmail> implementation will already inherit from <tabbrowser> to make it easier to enable mixing in the future - but for now that, won't be the case. Having the ability to restore multiple mail/message windows would be good, though. I hear your pain about sessionstore.js, we have forked it ourselves. I'm pretty sure that a generic base implementation in toolkit that could be shared between Firefox, Fennec, Thunderbird and SeaMonkey (on which we can base our different implementations) would probably be a good idea for the future. I'm CCing Mnyromyr, who is working on SeaMonkey tabmail, so he know about those efforts.

(In reply to comment #20) > A patch is up on bug 498106 that provides tab persistence for folder and > message tabs. I'm not sure if you already said this, but I'm hoping that Session Restore will be flexible enough to allow extensions like Lightning to save whatever arbitrary data they want on a per-tab basis. Although I don't know the intentions of the Calendar team, here are a couple of hypothetical examples: 1) Restore one calendar tab in Day view and another one in Month view. 2) Restore one calendar tab with calendars A, B, and C selected, another tab with A and D.

See bug 451451 for discussions about tabbrowser in toolkit. Not moving fast, fwiw.

(In reply to comment #21) > I'm pretty sure that a generic base implementation in toolkit that could be > shared between Firefox, Fennec, Thunderbird and SeaMonkey (on which we can > base our different implementations) would probably be a good idea for the > future. That's bug 449967. I do have an API suggestion, have never got any feedback or interest at all.

I am marking this fixed because the fix for bug 498106 which implements tab persistence has landed. It remains to be seen if we will need to turn to clarkbw's UX-ing because performance issues make it untenable to automatically restore everything. My hope is that using a staged asynchronous restoration (which we do not currently do!) will prove sufficient mitigation for worst-case scenarions, so we will not have to do so. Since it will fall to clarkbw to provide UX input if we fail, I feel optimistic that he will know where to find his previous work rather than starting from scratch even if this bug is closed.

Although restoration of folders and messages in tabs works now, what needs to happen so that Lightning's Calendar or Tasks tabs are restored as well? This was used to sell accelerator changes in bug 477091#c18 ...

(In reply to comment #26) For Lightning see Bug 459381.