Paul O’Shannessy

blah. blah. blah.

max_concurrent_tabs is Dead; Long Live restore_on_demand

Since last September, you could set browser.sessionstore.max_concurrent_tabs to 0, and you would essentially have a built-in BarTab. I slipped that in later in the Firefox 4 release cycle as a part of cascaded session restore, but it required going into about:config and changing a preference value (or installing something like BarTab Lite).

Starting with the latest nightly (and soon to be Aurora 8), browser.sessionstore.max_concurrent_tabs is no more. We’re no longer allowing you to specify a specific number of tabs to restore concurrently. Instead we now allow you to either restore on demand, or use the hard-coded 3 tabs at a time value. The new preference is called browser.sessionstore.restore_on_demand. If you had customized max_concurrent_tabs and set it to 0, then restore_on_demand will be migrated to true. Unlike the old preference, restore_on_demand is exposed in the Preferences/Options dialog to make it accessible to a larger audience.

For the details, check out bug 648683.

Just Quit It

For a long time now, if you didn’t have Firefox set to restore your session then Firefox would prompt you before quitting. A dialog with 3 buttons and a checkbox. It looked like this:

That mostly just gets in your way though. You’ve already decided you want to quit. You don’t also need to decide if you want to reopen your tabs next time. So starting with the next nightly (January 21st) and Firefox 4 beta 10, you will no longer see that prompt. Of course if you already checked the box to “not ask next time” you weren’t seeing this anyway.

Essentially, all we did was flip a preference that has been there since Firefox 3 (that was almost 3 years ago for those of you keeping track at home). browser.warnOnQuit was added as hidden preference to override other conditions that might cause a dialog shown at quit. We set that to false. If you want Firefox 3.* behavior, then just flip the pref back to true.

If you’re interested, this was done in bug 592822 (it was originally planned as part of bug 588482).

Dude, Where’s My Session?

I know it’s been a while since I wrote about it, but it’s now possible to restore your session on demand after startup. There is work underway to make that feature more visible, namely bug 593421 (to add a button on the start page) and bug 589665 (to add a button in Panorama).

Update (Feb. 7, 2011): We had to make some further changes. We kept the dialog turned off by default but had to do some work with preferences. Setting browser.warnOnQuit is no longer good enough to show the quit dialog. Read more

Cascaded Session Restore + a Hidden Bonus

In the tradition of announcing major things on Friday nights…

I did this thing where we don’t load all of your pages at once when we restore your session. That should keep your Firefox (and computer in general) a bit more usable when you start up Firefox with a large session. See bug 586068 if you’re interested in the juicy details.

Other Details

  • Switching tabs should cause the selected tab to start loading immediately, even if it wasn’t loading before
  • This works with Panorama (so changing groups re-prioritizes your load order).

Preference Controlled

We load a certain number of tabs based on the browser.sessionstore.max_concurrent_tabs preference. We’ve set the default to 3 for now.

Hidden Bonus

Set the pref to 0. It’s basically a built-in BarTab.


We show the page title and favicon at start up, before we try to load the page. So you might see some slightly odd behavior. Panorama’s thumbnail caching isn’t perfect, so there will probably be missing thumbnails at start up if you switch into the Panorama view.

Please email me (link below!) or file a bug blocking 586068 if you see anything weird.

Restore Previous Session

I landed bug 588482 today (September 10th), so starting with tomorrow’s nightly version of Firefox (AKA Minefield), you’ll be able to restore your previous session at any point after start up. This means that you no longer have to restore your whole session immediately at start up. This will be available through a menu item in the History menu, as shown below.

Screenshot of History Menu

This feature will be in Firefox 4 beta 6 beta 7, due out in the next couple weeks.


  • Restoring your previous session after you’ve browsed around will merge the sessions. You shouldn’t lose any new data by restoring your previous session.
  • We didn’t break existing behavior. If you have Firefox set to show your windows and tabs from last time, we’ll continue to do so and you won’t even notice this feature exists
  • App tabs still behave the same.
  • This doesn’t break any existing APIs, but it does add some new ones.
  • Discoverability is suboptimal.
  • You are still prompted to save your session when quitting (assuming default prefs).


We did this primarily for 2 reasons.

  1. We want faster start up times. By encouraging users to always resume their previous sessions, we give the impression that Firefox takes a long time to load up. But really, you’re loading 20, 50, 100+ tabs and that’s what is slow.
  2. When you’re quitting, you there’s a good chance you have no idea if you’ll need your tabs next time.

(Keep in mind, if you’re reading this post, you aren’t the typical user. You’re probably a developer of some sort who drags your 400 tabs around to each session. You know it’s slow, but you really never got the hang of bookmarks, so you just keep tabs open.)


Obviously, in order for us to restore your session, we need to save it to disk. We save this data in a plain-text JSON file in your profile.

We currently consider sessions a little differently than some other browsers. We consider your session cookies (and a few other things) as part of your session. This means we write that information to disk. Under a normal session restore that you’ve explicitly opted-in to, that’s fine. We have a hidden preference (browser.sessionstore.privacy_level) that specifies what level of privacy to use. The default value is 1.

There are 3 levels of privacy:

  • 0 = Save private information for HTTP and HTTPS sites.
  • 1 = Save private information for HTTP sites.
  • 2 = Don’t save any private information.

For deferred sessions, we created a new preference (browser.sessionstore.privacy_level_deferred) with a different default value. Since people are not making an informed decision to restore at shutdown, we don’t want to expose information that can be used to, for example, log in to GMail. This new preference has the same possible values but the default value is 2, so that no session cookies will be restored.


Yea. They’ve been doing this for ages. But as far as I know, they still don’t allow you to restore your entire session at start up.

Now Using JSON.parse in Session Restore

Back in March, I partially dropped support for sessions from Firefox 2.0 & 3.0. For Firefox 4.0, we’ll be dropping backwards compatibility of sessions for Firefox 2.0 & 3.0. That means that sessions created with nightlies starting tomorrow, will no longer be loadable by versions of Firefox prior to 3.5. With bug 387859, Session Restore will now use JSON.parse instead of evalInSandbox.

So why use JSON.parse?

Mostly, it’s faster. evalInSandbox involved going through XPConnect and a whole bunch of object wrapping for security needed to be done. By using JSON.parse, we don’t have to worry about that overhead. We also don’t have to worry about changes made to Chrome Object Wrappers (changes which have broken about:sessionrestore recently).

What does this mean for me? Not Much.

  • If for some reason you’re bouncing between nightlies and Firefox 3.0, then you’ll want to load your session in Firefox 3.5 or 3.6 before loading it in Firefox 3.0 again. If this describes you, then you should really just upgrade.
  • The contents of sessionstore.js will no longer have wrapping parenthesis. Those were added so that sessions could still be loaded by Firefox 3.0-.
  • The keys that were only ever used internally are now excluded from exported sessions. This includes _tabStillLoading, _hosts, and _formDataSaved.

(Partially) Dropping Support for Firefox 2.0/3.0 Sessions

Note: This does not affect Firefox 3.5 or 3.6 users!

Today I landed a patch for bug 551285, which removes support for certain parts of sessions created in Firefox 2.0 and 3.0. This means that if you upgrade directly from 2.0 or 3.0 to (currently 3.7), you will lose some session data.

The data you would lose is limited to the following:

  • Form data (2.0 and 3.0)
  • Session Cookies (2.0 only)
  • Tab XUL Attributes (2.0 and 3.0)
  • Session History Post Data (2.0 only)
  • Session History Owner (2.0 only)

If losing any of this data particularly bothers you, then it’s as simple as upgrading to Firefox 3.6 or Firefox 3.5 first. Alternatively, some session management add-ons could update your session file for you (for example, the author of Session Manager is updating his add-on to do that).