Closed Bug 588482 Opened 14 years ago Closed 14 years ago

Restore Session on-demand after startup

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 4.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: zpao, Assigned: zpao)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, relnote, user-doc-needed, Whiteboard: [strings])

Attachments

(1 file, 7 obsolete files)

Patch v1.0 (for checkin)
45.73 KB, patch
Details | Diff | Splinter Review 
Plan:
* A "widget" on the home tab for session restore
  - a button on the home tab to restore your session
  - a 2nd button on the home tab to restore part of your session
  - a checkbox to "always restore at startup"
* repurposing about:sessionrestore (STRINGS!) to specify that you're restoring part of your session (not necessarily that Firefox crashed)
* cleaning up the dialogs on quit/window close
  - don't show any session related dialogs when quitting

Backup Plan (in case we don't get the home tab we want)
* Same thing except using a submenu in the history menu

Will do if there's time:
* Clean up the "start up" section of the general pref pane.

Further plans (followup?)
* Add "undo close window" to the home tab widget
* Some dialog work likely in another bug (bug 384907)

We're probably going to have to add to our APIs and definitely will need to add string, so this should happen "with haste".
This is (part of) what we'll do to attack the slowness around session restore. This should block beta5 since it's a pretty big change in behavior (and will require some string & likely API changes)
Blocks: 582005
blocking2.0: --- → ?
I think we'll also want a way to offer this in tab candy's overview view.
blocking2.0: ? → beta5+
Attached patch Patch v0.1 (WIP) (obsolete) — — Splinter Review 
A quick patch. So far this was done with as few changes breakages as possible. One of my big concerns here was the "sessionstore-windows-restored" notification, which has sort of become a secondary delayed startup. Unless something else comes up, it looks like we don't actually need to change the meaning of that notification or add any new ones. My other concern was prefs, but so far so good.

However... App Tabs haven't really been considered. It's a bit tough to make the right call there though unless we really pin down the right behavior for app tabs (ohai bug 587873). With this patch, they aren't restored at startup until you restore your session. That's not the right thing to do, but since you can have different app tabs in different windows, it's awkward to start up with multiple windows and then have a separate "restore your session" step.
Attachment #467326 - Flags: feedback?(dietrich)
If App Tabs were global across all windows, would this be easier to accomplish?
(In reply to comment #4)
> If App Tabs were global across all windows, would this be easier to accomplish?

Yes and no.

Yes in that I know exactly what's supposed to happen. I think it makes a better experience, though there are things to figure out (eg. what if an app tab is crashing your session?). If app tabs were truly global, then restoring them becomes a "distinct" step from restoring the rest of your session.

No in that it means I have to make a better distinction for app tabs in session restore (would happen in the other bug, which shouldn't be *too* bad), and probably a bit more work all around. Could be that it's more work, but easier to do; I can't really say.

There's going to have to be work to fit app tabs into this regardless. I don't think that's really the answer you were looking for, but here we are :/

If I had to make a UX decision, I would say that app tabs should be global otherwise they are just pinned tabs and they aren't really very special (just shorter tabs) and should just be stored as part of your session.
Yup - was mostly looking for an understanding of "is there work to do either way the UX decision slices". Good to know. Limi and I are looking at the UX question tomorrow.
Attached patch Patch v0.2 (WIP) (obsolete) — — Splinter Review 
In which I repurpose about:sessionrestore for more general use. I also started working on the all important part where we don't prompt at quit.
Attachment #467326 - Attachment is obsolete: true
Attachment #467680 - Flags: feedback?(dietrich)
Attachment #467326 - Flags: feedback?(dietrich)
Comment on attachment 467680 [details] [diff] [review]
Patch v0.2 (WIP)

f+ on the general approach.
Attachment #467680 - Flags: feedback?(dietrich) → feedback+
--> beta6, at this point, I'm pretty sure.
blocking2.0: beta5+ → beta6+
When we restore, we've sort of settled on the behavior that we restore your pinned tabs and start a new session. Great... except it gets awkward. Currently we're expecting to fold app tabs into the main window, which is probably the best thing to do.

Take this case (Caps denote pinned tabs)

+ Window 1
 - Tab A
 - Tab b
+ Window 2
 - Tab Z
 - Tab y

So at startup we have:

+ Window 1
 - Tab A
 - Tab Z
 - home page(s), other browsing

Then we manually restore - things get awkward here.

+ Window 1
 - Tab A
 - Tab Z
 - home page(s), other browsing
+ Window 2
 - Tab b
+ Window 3
 - Tab y

I'm mostly OK with keeping it like this to land ASAP and fixing after freeze, thought I'm not completely sure what "fixing" this would mean. Thoughts?
There's also the problem with cookies... Presumably if you have GMail in an app tab and then restore, you should remain logged in. However cookies are currently stored & restored on a window basis.

Should we restore all cookies if you have app tabs? (NO - you'd never lose those cookies)

Should we make it so we can get at cookies (more specifically, "hosts" for cookies) on a per tab basis? (probably)
(In reply to comment #11)
> There's also the problem with cookies... Presumably if you have GMail in an app
> tab and then restore, you should remain logged in. However cookies are
> currently stored & restored on a window basis.
> 
> Should we restore all cookies if you have app tabs? (NO - you'd never lose
> those cookies)
> 
> Should we make it so we can get at cookies (more specifically, "hosts" for
> cookies) on a per tab basis? (probably)

Err, oversight on my side. We do this all inside session restore so it's doable. It might result in some extra cookies restored (ones for history entries in the app tab but not necessarily matching the current host), but that's ok.
(In reply to comment #10)
> we're expecting to fold app tabs into the main window, which is probably the
> best thing to do.

Not sure if you read through the entire spec (as we'd talked about it over IRC and in email) but I actually changed that a little here:

https://wiki.mozilla.org/Firefox/Projects/App_Tabs#Persistence

Having thought more about this (and indeed, the scenario you mention!) I actually think that if a user has gone through the trouble of creating N windows and pinning tabs in M of those Windows, then we should restore all M windows with pinned tabs.

Does that help?
Attached patch Patch v0.3 (WIP) (obsolete) — — Splinter Review 
Still a WIP, but it's getting really close...

Progress since last time:
* App tabs will be restored - they will be restored into whatever window arrangement they were in before
* Cookies from app tabs will be restored with those tabs
* When restoring your previous session, the tabs will be restored into the window they were in before (ie, back into the window with app tabs it had before)
  - still some work around the edges (make sure PB transitions are handled)
* Took out some unrelated work.

Still to do:
* Some PB mode handling
* Take out the dialog changes. It's related but we can do it later - probably better to get this out sooner & do followup work.
* Better strings

Anybody have some spare time & want to look at a 40k patch (most of it is in sessionstore)?
Attachment #467680 - Attachment is obsolete: true
Whiteboard: [strings]
Per a chat with Faaborg, we're going to simplify this down to a single menu entry to restore your whole last session. That makes things a lot more simple here and reduces our string changes.

Also, AHHH! I just realized this is probably going to be pretty awful for Tab Candy when you are merging the previous session into an existing session... I haven't actually tested that though...
FWIW, if there are still alternative headings after the redo, I'd prefer them to be both in the xhtml doc, and just have their visibility/display switched instead of putting the page together in parts by DTD and .properties.
(In reply to comment #16)
> FWIW, if there are still alternative headings after the redo, I'd prefer them
> to be both in the xhtml doc, and just have their visibility/display switched
> instead of putting the page together in parts by DTD and .properties.

That's fair - I was feeling a bit like Dr. Frankenstein when I was doing that.
Paul, can I get a little more information on what this means and what it implies for Tab Candy?
(In reply to comment #18)
> Paul, can I get a little more information on what this means and what it
> implies for Tab Candy?

We chatted on IRC and after I tested this out briefly, it doesn't look like any tabs are going to be lost to the sweet candy ether, but there's a slightly weird interaction... I say ignore it and hope all is fixed with bug 588217 :)
Attached patch Patch v0.4 (obsolete) — — Splinter Review 
Still some minor things going on in there and a bunch of XXXzpao comments, but I think it's ready to get a solid review on it, especially since the bulk of this is in session restore.
Attachment #471055 - Attachment is obsolete: true
Attachment #471423 - Flags: review?(dietrich)
Comment on attachment 471423 [details] [diff] [review]
Patch v0.4

Dao - would you be able to look at the browser bits? There's not a whole lot. Note, I haven't actually tested on a win7 build yet, but I assume the firefox menu changes work.
Attachment #471423 - Flags: review?(dao)
Comment on attachment 471423 [details] [diff] [review]
Patch v0.4

>+function restoreLastSession() {
>+  let ss = Cc["@mozilla.org/browser/sessionstore;1"].
>+           getService(Ci.nsISessionStore);
>+  // This should never be called if canRestoreSession is false, but cover our
>+  // bases in case of a bad caller.
>+  try {
>+    ss.restoreLastSession();
>+  }
>+  catch (e) { dump("\n\n" + e + "\n\n"); };
>+}

dump isn't going to be useful without a shell. You should just let the caller hit the wall, i.e. call ss.restoreLastSession without catching the exception.
Attachment #471423 - Flags: review?(dao) → review+
Attached patch Patch v0.5 (obsolete) — — Splinter Review 
Now actually ready for Dietrich to look at. Go go gadget reviewer!
Attachment #471423 - Attachment is obsolete: true
Attachment #471767 - Flags: review?(dietrich)
Attachment #471423 - Flags: review?(dietrich)
Comment on attachment 471767 [details] [diff] [review]
Patch v0.5

r- for these issues below. the code-changes themselves look mostly ok, those comments follow.

- when i feedback+'d before, i thought you were laying the groundwork for a scenario where we never automatically restore - alternatively showing some UI to prompt for restore. but now that it's done, i don't see how this helps startup at all, so maybe i misunderstood the point of these changes? or is this only part of the changes? it looks like if the user restores every time, we still restore everything. if the user restarts due to add-on/update install, we still restore everything. if the user doesn't restore anything automatically, then nothing gets restored automatically. the net being that the startup behavior doesn't change for anyone. the only behavioral change i can see is that users who do not restore anything automatically now have the post-startup option to restore their last session.

- i'm concerned about the privacy effect of keeping all session data all the time. users expect things like history, cookies, and things they explicitly ask to be remembered. but now, that half-typed screed against the boss is still sitting on the hard drive, even though you thought it disappeared forever when you closed the browser...

- manual restore of last session gives duplicate first tab. str: don't restore at startup, so only my homepage is there. then i restore last session from the menu, and my homepage is opened with it, so that i have two homepage tabs open (plus whatever else is in the restored session).

>@@ -57,11 +57,12 @@ interface nsISessionStartup: nsISupports
>   /**
>    * What type of session we're restoring. If we have a session, we're
>    * either restoring state from a crash or restoring state that the user
>    * requested we save on shutdown.
>    */
>   const unsigned long NO_SESSION = 0;
>   const unsigned long RECOVER_SESSION = 1;
>   const unsigned long RESUME_SESSION = 2;
>+  const unsigned long DEFER_SESSION = 3;

doc nit: can you add a short description of the resulting browser behavior of each of these?

>@@ -1129,33 +1154,92 @@ SessionStoreService.prototype = {
>   persistTabAttribute: function sss_persistTabAttribute(aName) {
>     if (this.xulAttributes.indexOf(aName) != -1)
>       return; // this attribute is already being tracked
>     
>     this.xulAttributes.push(aName);
>     this.saveStateDelayed();
>   },
> 
>+  restoreLastSession: function sss_restoreLastSession() {

please add a comment summarizing the behavior.

>+    // Use the public getter since it also checks PB mode
>+    if (!this.canRestoreLastSession)
>+      throw "I'm sorry, Dave. I'm afraid I can't do that.";

hehe. something more useful to developers please.

>@@ -2926,29 +3000,145 @@ SessionStoreService.prototype = {
>     let sessionAge = aState.session && aState.session.lastUpdate &&
>                      (Date.now() - aState.session.lastUpdate);
>     
>     return max_resumed_crashes != -1 &&
>            (aRecentCrashes > max_resumed_crashes ||
>             sessionAge && sessionAge >= SIX_HOURS_IN_MS);
>   },
> 
>+  _prepDataForDeferredRestore: function sss__prepDataForDeferredRestore(stateString) {

please add a hefty comment explaining what exactly this does and why.

>+    // split data (much like in init:)
>+    // for opened windows, can we attach a __ss_restoredata
>+    // we then need to handle the PB mode transition
>+    //
>+    function extractHosts(aEntry, aHosts) {
>+      let match;
>+      if (((match = /^https?:\/\/(?:[^@\/\s]+@)?([\w.-]+)/.exec(aEntry.url)) != null ||
>+            (match = /^file:\/\/([^\/]*)/.exec(aEntry.url)) != null) &&
>+          aHosts.indexOf(match[1]) == -1)
>+        aHosts.push(match[1]);
>+      if (aEntry.children)
>+        aEntry.children.forEach(function (entry) extractHosts(entry, aHosts));
>+    }

this method is already gargantuan, so break this out into a separate one.

>+
>+    let state = JSON.parse(stateString);
>+    let iniState = { windows: [], selectedWindow: 1 };

nit: s/iniState/defaultState/ would be more descriptive

>+
>+    state.selectedWindow = state.selectedWindow;

wha?

>+
>+    // Look at each window, remove pinned tabs, adjust selectedindex, remove window if necessary

wrap

>+        // Extract the cookies that belong with each pinned tab
>+        if (window.cookies) {
>+          // Get the cookies we need for these app tabs
>+          let cookieHosts = [];
>+          pinnedWindowState.tabs.forEach(function(tab) {
>+            tab.entries.forEach(function(entry) {
>+              extractHosts(entry, cookieHosts)
>+            });
>+          });
>+          // By creating a regex we reduce overhead and there is only loop pass
>+          // through either array (cookieHosts and window.cookies).
>+          let cookieRegex = new RegExp(".*(" + cookieHosts.join("|").replace("\\.", "\\.", "g") + ")");
>+          for (let cIndex = 0; cIndex < window.cookies.length;) {
>+            if (cookieRegex.test(window.cookies[cIndex].host)) {
>+              pinnedWindowState.cookies =
>+                pinnedWindowState.cookies.concat(window.cookies.splice(cIndex, 1));
>+              continue;
>+            }
>+            cIndex++;
>+          }
>+        }

cookie extraction should also be broken out into a separate method. please think of the future generations that have to maintain this code.

>   _toJSONString: function sss_toJSONString(aJSObject) {
>+    // We never want to save __lastSessionWindowID across sessions, but we do
>+    // want it exported to consumers when running (eg. Private Browsing).

how will this affect add-ons that use the api for full or partial restores, like Session Manager?
Attachment #471767 - Flags: review?(dietrich) → review-
(In reply to comment #24)
> - when i feedback+'d before, i thought you were laying the groundwork for a
> scenario where we never automatically restore - alternatively showing some UI
> to prompt for restore. but now that it's done, i don't see how this helps
> startup at all, so maybe i misunderstood the point of these changes? or is this
> only part of the changes? it looks like if the user restores every time, we
> still restore everything.

FWIW, I wouldn't expect nor welcome a behavior change here. When I told Firefox to always restore my tabs, repeatedly asking me at startup will only slow me down.

> - i'm concerned about the privacy effect of keeping all session data all the
> time. users expect things like history, cookies, and things they explicitly ask
> to be remembered. but now, that half-typed screed against the boss is still
> sitting on the hard drive, even though you thought it disappeared forever when
> you closed the browser...

I'm concerned about this too, but I though it would be a known and accepted implication. There's no way to avoid this other than WONTFIXing this bug, is there?
(In reply to comment #24)
> Comment on attachment 471767 [details] [diff] [review]
> Patch v0.5
> 
> r- for these issues below. the code-changes themselves look mostly ok, those
> comments follow.
> 
> - when i feedback+'d before, i thought you were laying the groundwork for a
> scenario where we never automatically restore - alternatively showing some UI
> to prompt for restore. but now that it's done, i don't see how this helps
> startup at all, so maybe i misunderstood the point of these changes? or is this
> only part of the changes? it looks like if the user restores every time, we
> still restore everything. if the user restarts due to add-on/update install, we
> still restore everything. if the user doesn't restore anything automatically,
> then nothing gets restored automatically. the net being that the startup
> behavior doesn't change for anyone. the only behavioral change i can see is
> that users who do not restore anything automatically now have the post-startup
> option to restore their last session.

So the intention here wasn't to change too much behavior. If your pref was to restore at startup, we'll continue to do so. If we start up and resume_session_once is set (due to add-on install) then we will restore your session.

As it is, this patch doesn't remove/change the dialog you see when quitting. That's what bug 592822 is for. That is the part that is missing that really makes this feature valuable. Instead of seeing that dialog and prompting if you want to save your session, we just quit. If you want to restore, you can decide that when you start up.

> - i'm concerned about the privacy effect of keeping all session data all the
> time. users expect things like history, cookies, and things they explicitly ask
> to be remembered. but now, that half-typed screed against the boss is still
> sitting on the hard drive, even though you thought it disappeared forever when
> you closed the browser...

I was also under the impression we were writing this off as known.

> - manual restore of last session gives duplicate first tab. str: don't restore
> at startup, so only my homepage is there. then i restore last session from the
> menu, and my homepage is opened with it, so that i have two homepage tabs open
> (plus whatever else is in the restored session).

Yea, I saw this too, but wasn't sure the right way to handle it. We don't really want to wipe away the current session when restoring the previous, but homepage(s) might be a special case... I figured we could fix it in a followup since that is much less of a behavioral change and could happen post b6.

> >+
> >+    state.selectedWindow = state.selectedWindow;
> 
> wha?

That's supposed to have `|| 1` at the end (make sure we have a value in there)

> >   _toJSONString: function sss_toJSONString(aJSObject) {
> >+    // We never want to save __lastSessionWindowID across sessions, but we do
> >+    // want it exported to consumers when running (eg. Private Browsing).
> 
> how will this affect add-ons that use the api for full or partial restores,
> like Session Manager?

Callers of getBrowserState/getWindowState will have __lastSessionWindowID in the data. This was pretty much just so entering/exiting private browsing would still allow restoring into the existing windows. however we won't save it across sessions and it gets wiped when you restore the previous session on demand, so it shouldn't ever be an issue with add-ons AFAIK.

It's a random id correlated with data that's not exposed and it's only exists if there were pinned tabs.
Attached patch Patch v0.6 (obsolete) — — Splinter Review 
Addressed review comments. Haven't figured out exactly what the plan is for privacy, but I started a thread on DAF to get some feedback: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/04f1610105f1a894
Attachment #471767 - Attachment is obsolete: true
Attachment #472211 - Flags: review?(dietrich)
Comment on attachment 472211 [details] [diff] [review]
Patch v0.6


>+  /**
>+   * Restore the previous session if possible. Current windows will be reused if
>+   * they were windows that pinned tabs were previously restored into. New
>+   * windows will be opened as needed.
>+   *
>+   * Note: This will throw if there is no previous state to restore. Check with
>+   * canRestoreLastSession first to avoid thrown errors.
>+   */
>+  void restoreLastSession();

specifically needs to note that it doesn't write over the current session, but merges with it.

almost there. this'll get r+ with the following:

1. beltzner's change noted in DAF: need to not restore session cookies when doing deferred restoration.

2. tests
Attachment #472211 - Flags: review?(dietrich) → review-
Comment on attachment 472211 [details] [diff] [review]
Patch v0.6


>+  /**
>+   * Restore the previous session if possible. Current windows will be reused if
>+   * they were windows that pinned tabs were previously restored into. New
>+   * windows will be opened as needed.
>+   *
>+   * Note: This will throw if there is no previous state to restore. Check with
>+   * canRestoreLastSession first to avoid thrown errors.
>+   */
>+  void restoreLastSession();

specifically needs to note that it doesn't write over the current session, but merges with it.

almost there. this'll get r+ with the following:

1. beltzner's change noted in DAF: need to not restore session cookies when doing deferred restoration.

2. tests
> 1. beltzner's change noted in DAF: need to not restore session cookies when
> doing deferred restoration.

Agree that this should be the default state, modifiable by pref, hopefully reusing/adding to existing privacy pref for session restore.

I take it "deferred restoration" only happens on quit, not on restart, yes? What happens for things like forced quit in Windows (as done by Windows App Update) or power failure?
(In reply to comment #30)
> > 1. beltzner's change noted in DAF: need to not restore session cookies when
> > doing deferred restoration.
> 
> Agree that this should be the default state, modifiable by pref, hopefully
> reusing/adding to existing privacy pref for session restore.

Right, so like we talked about on IRC we have browser.sessionstore.privacy_level. 0 = save everything; 1 = don't save formdata/session cookies for HTTPS; 2 = don't save formdata/cookies at all. The default value is 1.

It's hard to reuse this pref without affecting restore from crash & normal restore session, which I don't think should change, so I think it best to add a new pref.

Let's try this by having a new pref browser.sessionstore.privacy_level_deferred with values of the same meaning. It will only apply at quit, and only with a deferred session. The default value will be 2.

> I take it "deferred restoration" only happens on quit, not on restart, yes?
> What happens for things like forced quit in Windows (as done by Windows App
> Update) or power failure?

Well, as it is, we just save the session, then determine at startup if it's a deferred session. We can figure it out at quit though and clean out that data.

As for forced quit or other crashes, that path doesn't change. We'll still treat that as a crash, so long as browser.sessionstore.resume_from_crash == true.

As for when that pref is false... I accidentally just broke that :( Before this patch, we were saving just the app tabs (per bug 580512 comment 31). I need to fix that.
(In reply to comment #29)
> almost there. this'll get r+ with the following:
> 
> 1. beltzner's change noted in DAF: need to not restore session cookies when
> doing deferred restoration.
> 
> 2. tests

So I think tests are going to be difficult. And by that I mean we need litmus and/or mozmill tests. I think the only mochitest we can do is check that canRestoreLastSession is false and restoreLastSession throws. Otherwise, this is really only in the startup/shutdown paths.
Attached patch Patch v0.7 (obsolete) — — Splinter Review 
* Adds a new pref as detailed in comment 31
* Details restoreLastSession in the IDL better
* Added back the pinned only stuff so that we handle resume_from_session == false (so only app tabs are restored)
* Added a layer of spaghetti to make sure that saved private data (session cookies, formdata, etc) never uses privacy_level_deferred, since pinned tabs will be restored all the time.

I'm not happy about that layer of spaghetti, but it really seems to be the best way to do it. Without it, app tabs (which will be restored even if the rest is deferred), will not keep their session cookies. So you would expect to stay logged in to GMail in an app tab, but not in a normal-deferred tab.
Attachment #472211 - Attachment is obsolete: true
Attachment #473728 - Flags: review?(dietrich)
Litmus/MozMill test cases.
Prereqs:
  1. browser.sessionstore.privacy_level = 1
  2. browser.sessionstore.privacy_level_deferred = 2
  3. browser.startup.page = 1
  --OR--
  1. a new profile, above are just default pref values
  --AND--
  1. a gmail account, should be set to only allow https (at least that's how I tested)

Session Cookie tests will all use 2 tabs:
  1. https://mail.google.com
  2. http://playground.zpao.com/mozilla/cookie.php

Session Cookie Test 1:
  1. Open tabs to sites above, log in to gmail
  2. Restart Firefox (don't save session, can say never save)
  3. Restore Previous Session (History menu)
    --Expected Results--
    1. Gmail is logged out
    2. Test cookie page doesn't show cookie value

Session Cookie Test 2:
  1. Set browser.sessionstore.privacy_level_deferred to 1
  2-4. Follow steps from Cookie Test 1
    --Expected Results--
    1. Gmail is logged out
    2. Test cookie page shows cookie value

Session Cookie Test 3:
  1. Set browser.sessionstore.privacy_level_deferred to 0
  2-4. Follow steps from Cookie Test 1
    --Expected Results--
    1. Gmail stays logged in
    2. Test cookie page shows cookie value

Session Cookie Test 4
  1. Set browser.sessionstore.privacy_level_deferred = 2; privacy_level = 1
  2. Open tabs to sites
  3. Make Cookie Test (zpao.com) an app tab
  4. Restart Firefox (don't save session)
    --Expected Results--
    1. App tab should be open to test cookie page
    2. Test cookie page shows cookie value
  5. Restore Previous Session
    --Expected Results--
    3. Gmail is logged out

Session Cookie Test 5
  1. Set browser.sessionstore.privacy_level_deferred = 2; privacy_level = 1
  2. Open tabs to sites
  3. Make Gmail an app tab
  4. Restart Firefox (don't save session)
    --Expected Results--
    1. App tab should be open to test cookie page
    2. Gmail is logged out
  5. Restore Previous Session
    --Expected Results--
    3. Test cookie page doesn't shows cookie value

Session Cookie Test 5
  1. Set browser.sessionstore.privacy_level_deferred = 2; privacy_level = 0
  2. Open tabs to sites
  3. Make Gmail an app tab
  4. Restart Firefox (don't save session)
    --Expected Results--
    1. App tab should be open to test cookie page
    2. Gmail is still logged in
  5. Restore Previous Session
    --Expected Results--
    3. Test cookie page doesn't shows cookie value

Note: Could (should?) do the same tests with HTTPS vs HTTP for form data, sessionstorage; but it follows the same checks so should be the same as session cookies

Other Tests:
  1. Make sure that History > Restore Last Session is disabled after you click on it.
  2. Make sure that History > Restore Last Session is disabled if your session is auto-resumed (startup = restore windows & tabs)
  3. Make sure that History > Restore Last Session is disabled if you delete sessionstore.js between sessions.
Comment on attachment 473728 [details] [diff] [review]
Patch v0.7

>   _updateCookies: function sss_updateCookies(aWindows) {
>@@ -1690,21 +1815,24 @@ SessionStoreService.prototype = {
>     for (var i = 0; i < aWindows.length; i++)
>       aWindows[i].cookies = [];
> 
>     var jscookies = {};
>     var _this = this;
>     // MAX_EXPIRY should be 2^63-1, but JavaScript can't handle that precision
>     var MAX_EXPIRY = Math.pow(2, 62);
>     aWindows.forEach(function(aWindow) {
>-      for (var host in aWindow._hosts) {
>+      for (var [host, isPinned] in Iterator(aWindow._hosts)) {

So there were some failures on try here. JavaScript Error: "aWindow._hosts is undefined". So assume this has the following right above the change...
> if (!aWindow._hosts)
>   return;

I never hit that in my manual testing and aWindow._hosts *should* be defined (first line in _updateCookieHosts), but ok.

Try builds available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/poshannessy@mozilla.com-6b90c32ed00d/
Talos is running to make sure this isn't going to cause any unexpected regressions.
Comment on attachment 473728 [details] [diff] [review]
Patch v0.7

outside of some line-length problems, r=me. please fix those for checkin.
Attachment #473728 - Flags: review?(dietrich) → review+
Fixed line length issues (as much as possible without making things too awkward) and the other fix I mentioned above.
Attachment #473728 - Attachment is obsolete: true
Pushed http://hg.mozilla.org/mozilla-central/rev/d8502fae9678
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
We've got some new APIs, so dev-doc-needed
Keywords: dev-doc-needed
Summary: Restore Session on-demand at startup → Restore Session on-demand after startup
Flags: in-litmus? → in-litmus?(anthony.s.hughes)
Blocks: 614220
Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12813

Verified FIXED using Minefield 4.0b8pre 2010-12-02.
Status: RESOLVED → VERIFIED
Flags: in-litmus?(anthony.s.hughes) → in-litmus+
I'm unable to find the option to automatically restore a session on startup? Is there no option for that? Is that intended?
Scratch that. It's been pointed out to me.
Keywords: relnote, user-doc-needed
Blocks: 561152
Depends on: 818891
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: