Applications such as Thunderbird, SeaMonkey, etc. want to use window session management as well. Their task would be simplified, if we factored out the generally useful bits of nsSessionStore.js and shipped them with all XULRunner based applications. See the URL for an API proposal. Please add comments about that proposal either to the wiki's discussion page or to the thread in <news://news.mozilla.org/mozilla.dev.platform>.

SeaMonkey maybe; but Thunderbird???

> SeaMonkey maybe; but Thunderbird??? Thunderbird developers have expressed interest is similar functionality. I don't know how it will affect SeaMonkey as we have a fairly complete implementation patch waiting for final r/sr.

(In reply to comment #2) > Thunderbird developers have expressed interest is similar functionality. I wonder what they want to save, Tb has no tabs after all - but time will tell. > I don't know how it will affect SeaMonkey as we have a fairly complete > implementation patch waiting for final r/sr. yeah, I thought that much. I should have said "maybe, maybe not".

> I wonder what they want to save, Window state data for example. > Tb has no tabs after all There is a patch[1] that adds tabs to TB trunk builds. It may have been checked in recently. [1] This patch adds tabs to the whole three pane window. An different earlier patch added tabs to only the message pane but was never approved.

Tb trunk has had tabs for a little over a year.

Another potential consumer of this feature: http://bugzilla.songbirdnest.com/show_bug.cgi?id=895

This patch moves the common parts to toolkit/, with some jsm renaming. Tests were green locally, here's a try run: https://tbpl.mozilla.org/?tree=Try&rev=43752bbaad3b

Now with the missing files. https://tbpl.mozilla.org/?tree=Try&rev=72feffcb9b01

Comment on attachment 8422744 [details] [diff] [review] sessionstore-toolkit.patch Review of attachment 8422744 [details] [diff] [review]: ----------------------------------------------------------------- Why are we moving code to toolkit? Who are the consumers? Why are we cherry-picking JSMs? Why those JSMs exactly?

We need session store on b2g, so it makes sense to reuse the content part that was written for desktop e10s. I just moved this part and the dependent jsm to toolkit/. b2g will have a different implementation in the parent since it doesn't deal with windows & tabs in the same way.

Comment on attachment 8422744 [details] [diff] [review] sessionstore-toolkit.patch Review of attachment 8422744 [details] [diff] [review]: ----------------------------------------------------------------- Does it really make sense for B2G to use the frame script as is? The PageStyle and DocShellCapabilities seem like data that B2G isn't interested in. We're also having a few plans to move to smaller more differential updates being sent by the frame script in the near future and I wouldn't like to have that blocked by B2G. That sounds like we would end up forking the frame script anyway so I wonder if it wouldn't be better if we only shared the necessary JSMs? Also ContentRestore.jsm together with the frame script is very tied to how the tabbrowser creates and restores tabs so we probably should exclude that.

XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context. I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #13) > XULRunner has been removed from the Mozilla tree: see > https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for > context. > > I am closing all the bugs currently in the XULRunner bugzilla component, in > preparation for moving this component to the graveyard. If this bug is still > valid in a XULRunner-less world, it will need to be moved to a different > bugzilla component to be reopened. This was about generalizing SessionStore for all Toolkit applications. IMHO it was put under xulrunner as some kind of fallback component, but it concerns Thunderbird and SeaMonkey more than xulrunner. Let's try to find some still alive component.

Toolkit::Storage is about the SQLite binding layer found in mozilla-central/storage. Looking at the bugs filed against browser/components/sessionstore, it looks like the best home for this bug is Firefox::Session Restore where it may get marked WONTFIX. Moving.

(In reply to Andrew Sutherland [:asuth] from comment #15) > Toolkit::Storage is about the SQLite binding layer found in > mozilla-central/storage. Looking at the bugs filed against > browser/components/sessionstore, it looks like the best home for this bug is > Firefox::Session Restore where it may get marked WONTFIX. Moving. In Firefox it's already WORKSFORME. The idea of this bug is, on the contrary, to move it (or copy it) to somewhere in Toolkit, or failing that, to somewhere in comm-central.

I think it's probably a non-goal to generalize this. If you want to fork this for seamonkey/etc that's fine.