1280590 - When logged into okta in the default container and non-default container, restarting the browser will log you out of okta in the non-default container

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P1)

Description

[Dave Townsend [:mossop]]

I opened a pinned tab to Gmail signed in as my mozilla account. After restarting that tab went back to the login screen so I assume it lost its cookies. This seems reproducible.

Comment 1

[Kamil Jozwiak [:kjozwiak]]

I can only reproduce this with my Mozilla Gmail account. Perhaps it has something to do with Okta. When going through the test case with my personal gmail account (using 2fa as well), I couldn't reproduce the problem.

Looks like this issue has been around for a while, I tried going through some mozregression ranges, and could reproduce with the following builds:

* fx49.0a1, buildid: 20160501030217, changeset: 1461a4071341c282afcf7b72e33036412d2251d4
* fx49.0a1, buildid: 20160501030217, changeset: 1461a4071341c282afcf7b72e33036412d2251d4
* fx47.0a1, buildid: 20160301030237, changeset: 8ef94be995a453f5c464278c53478ba8c8554f81
* fx47.0a1, buildid: 20160201030241, changeset: 941033a51983ddec2d99aa9f868a54c0196a4075
* fx46.0a1, buildid: 20160101030330, changeset: 22f51211915bf7daff076180847a7140d35aa353

STR:

* launch a new profile in m-c
* create a new container via File -> New Container Tab -> Personal
* login into Gmail (Mozilla) using Okta
* once logged in, pin the tab via right clicking the Personal Container and selecting "Pin Tab"
* restart fx

Comment 2

[Jonathan Hao (inactive) [:jhao]]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #1)
> I can only reproduce this with my Mozilla Gmail account. Perhaps it has
> something to do with Okta. When going through the test case with my personal
> gmail account (using 2fa as well), I couldn't reproduce the problem.
> 
> Looks like this issue has been around for a while, I tried going through
> some mozregression ranges, and could reproduce with the following builds:
> 
> * fx49.0a1, buildid: 20160501030217, changeset:
> 1461a4071341c282afcf7b72e33036412d2251d4
> * fx49.0a1, buildid: 20160501030217, changeset:
> 1461a4071341c282afcf7b72e33036412d2251d4
> * fx47.0a1, buildid: 20160301030237, changeset:
> 8ef94be995a453f5c464278c53478ba8c8554f81
> * fx47.0a1, buildid: 20160201030241, changeset:
> 941033a51983ddec2d99aa9f868a54c0196a4075
> * fx46.0a1, buildid: 20160101030330, changeset:
> 22f51211915bf7daff076180847a7140d35aa353
> 
> STR:
> 
> * launch a new profile in m-c
> * create a new container via File -> New Container Tab -> Personal
> * login into Gmail (Mozilla) using Okta
> * once logged in, pin the tab via right clicking the Personal Container and
> selecting "Pin Tab"
> * restart fx

I can reproduce this with the above STR using default container only, so I assume this is not related to container.

Dave and Kamil, if you can confirm this, we should change this bug's component to, I don't know, Networking::Cookies, maybe?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

I have this problem, but only if the pinned tab is in a non-default container.

Comment 4

[Jonathan Hao (inactive) [:jhao]]

Here's how I reproduce this bug without using any non-default containers:
https://youtu.be/vyfBRkjPgUQ

Comment 5

[Tanvi Vyas[:tanvi]]

May be related to okta, but not sure.

We also need to see if this is really pinned tab specific or regular tabs have the same issue.

Comment 6

[Paul Theriault [:pauljt] (no longer reading bugmail)]

This _is_ a containers issue I think. Disabling containers (privacy.userContext.enabled ==false) fixes the bug.
I tested in both release (47) and nightly (50).

STR:
1. Make sure Firefox is configured to "show windows and tabs from last time" on startup (under preferences-> general)
2. Ensure containers is enabled (privacy.userContext.enabled == true)
3.Open 4 tabs, 2 pinned and 2 regular as follows
 - pinned, default container
 - pinned, work container
 - unpinned, default container
 - unpinned, work container
4. Load https://misuse.co/containers/cookies.html in ALL tabs
5. In one of the default containers set the cookie to 'default'. 
6. In one of the work tabs, set the cookie to 'work'
7. Observe that default is set in the default container, work is set in the work container
8. Quit the browser and re-open

Result:
Upon reopening, NEITHER tab open in the default context no longer has a cookie set. The work tabs do still have a cookie set though.

Expected:
Session restore should restore the session cookies to the same state before closing. 


Actually I just realised that its more complex that this, but keeping this comment since it is accurate STR

Comment 7

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Actually the STR doesnt have to involve pinned tabs. The behavior I see here is that session restore ONLY restores the LAST session cookie that was set.

STR:
1. Open two tabs, in seperate containers (e.g. work and bank)
2. Load https://misuse.co/containers/cookies.html in ALL tabs
3. Set the cookie to the container name (e.g. "work" in work and "bank" in bank) NOTING the order in which you set it
4. quit firefox and reopen

Result:
Only the last tab has a session cookie still set. IE if you did work then bank, only the bank tab has a cookie still.

Expected:
Both tabs still have a session cookie.

Comment 8

[Jonathan Hao (inactive) [:jhao]]

Clearing needinfo as Paul seems to have a clear idea about what's wrong.

BTW, even if I turned off privacy.userContext.enabled, I still got logged out from mozilla gmail.

Comment 9

[Tanvi Vyas[:tanvi]]

What Paul and Jonathan are saying here doesn't seem to match up.  Jonathan says we can reproduce without containers and Paul says it's a containers issue.  So it seems like we need to do some more testing here.

Comment 10

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Jonathan Hao [:jhao] from comment #8)
> Clearing needinfo as Paul seems to have a clear idea about what's wrong.
> 
> BTW, even if I turned off privacy.userContext.enabled, I still got logged
> out from mozilla gmail.

Not sure about gmail. Did you have session restore enabled? 

Actually Dave - can you confirm that you have your browser set to restore the previously open windows?

Comment 11

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Tanvi Vyas[:tanvi] from comment #9)
> What Paul and Jonathan are saying here doesn't seem to match up.  Jonathan
> says we can reproduce without containers and Paul says it's a containers
> issue.  So it seems like we need to do some more testing here.

I'm still testing/reviewing. But this is an issue I think:

http://searchfox.org/mozilla-central/source/browser/components/sessionstore/SessionCookies.jsm#67

The cookie storing/restore logic doesn't have any contept of containers, so I think thats the issue here. Or at least that is the issue which causes only one session cookie to be restored.

That would explain gmail not being logged in, but it might not be the only issue with Gmail/Okta.

Comment 12

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Never mind Dave, I've confirmed that Gmail auth cookies _are_ session cookies (IE they SHOULDN'T be saved after closing your browser, except the user has session restore enabled). Note in comment 4, jhao uses a new profile which by default does NOT have session restore enabled, hence why he is seeing the behavior of not being logged in after restarting the browser.

Comment 13

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Actually, I just realised Dave didn't say anything about containers. The bug I found is definitely a containers issue. Dave, can you confirm that you did have containers enabled. If not, then perhaps then Dave's bug was a dupe of bug 1264192? Or perhaps something else. 

But FWIW, I can't reproduce without containers. Both normal gmail , and mozilla/okta gmail both restore properly if I close the browser and re-open it.

Comment 14

[Jonathan Hao (inactive) [:jhao]]

(In reply to Paul Theriault [:pauljt] from comment #12)
> Never mind Dave, I've confirmed that Gmail auth cookies _are_ session
> cookies (IE they SHOULDN'T be saved after closing your browser, except the
> user has session restore enabled). Note in comment 4, jhao uses a new
> profile which by default does NOT have session restore enabled, hence why he
> is seeing the behavior of not being logged in after restarting the browser.

Note that I clicked "Remember me" in okta login page and "Remember this device" in 2FA page. So even though I didn't have session restore enabled, shouldn't I still be logged in?

This might be a separate okta bug, though.

Comment 15

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Jonathan Hao [:jhao] from comment #14)
> (In reply to Paul Theriault [:pauljt] from comment #12)
> > Never mind Dave, I've confirmed that Gmail auth cookies _are_ session
> > cookies (IE they SHOULDN'T be saved after closing your browser, except the
> > user has session restore enabled). Note in comment 4, jhao uses a new
> > profile which by default does NOT have session restore enabled, hence why he
> > is seeing the behavior of not being logged in after restarting the browser.
> 
> Note that I clicked "Remember me" in okta login page and "Remember this
> device" in 2FA page. So even though I didn't have session restore enabled,
> shouldn't I still be logged in?
> 
> This might be a separate okta bug, though.

I don't know what 'remember this device' actually does. I thought that was 'remember my second factor' - i.e. remember this device so that you only need to use your username & password to log for the next week. IE if you dont check that box, you will be asked for 2 factor every time you log in.

FWIW I just tested in Chrome, and Mozilla gmail does not stay logged in after a browser restart, even if you choose 'remember me' and 'remember this device'.

Comment 16

[Dave Townsend [:mossop]]

(In reply to Paul Theriault [:pauljt] from comment #13)
> Actually, I just realised Dave didn't say anything about containers. The bug
> I found is definitely a containers issue. Dave, can you confirm that you did
> have containers enabled. If not, then perhaps then Dave's bug was a dupe of
> bug 1264192? Or perhaps something else. 

Yes, the pinned tab in question was in the "Work" container. My other pinned tab which was signed into a personal gmail account kept itself logged in just fine (and has for many moons). I do have my tabs set to restore after a restart.

Comment 17

[Dave Townsend [:mossop]]

I should add that now it is no longer in a container my Mozilla gmail pinned tab is restoring just fine, but the setup is different because in this case I am signed into both my personal and work gmail in one session.

Comment 18

[Tanvi Vyas[:tanvi]]

Sounds like these are the two scenarios to compare:

* login to mozilla gmail in default container with containers disabled; click all the remember me options.  make sure your browser is set to restore tabs after restart.  make sure you are logged out of all other google accounts on that browser.  Report if you are still logged in after browser restart.  If you are not logged in, try and login and report whether you are prompted for your 2fa.



* login to mozilla gmail in work container with containers enabled; click all the remember me options.  make sure your browser is set to restore tabs after restart.  make sure you are logged out of all other google accounts on that browser.  Report if you are still logged in after browser restart.  If you are not logged in, try and login and report whether you are prompted for your 2fa.

Comment 19

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I have created a new bug 1283709 to solve the specific issue that I identified in comment 7.

I'm leaving this bug open to further investigate the Mozilla gmail issue.

Comment 20

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So I did a whole bunch of testing in nightly (table below). I also tested in release, dev & Chrome 51. 

My observations are:
* If session restore is enabled (i.e. firefox is set to restore your previous tabs on startup) I ALWAYS remained logged in. Didn't matter if tab was pinned or not, or in default container or a non-default one.
* If session restore is not-enabled, the pinned tab does NOT remain logged in, irrespective of if containers is enabled, or if you are using the default container or not. NOTE: you DON'T need to enter your password again, just enter your username, and it logs you in (which is weird? Its appears you are authenticated, but you need to select the user)
* For the single tab case, containers makes no difference to the result. The results were the same in release, dev edition and nightly. 
* I also tested in Chrome, but in Chrome you NEVER remain logged on restart, even if the tab is pinned.

Conclusion:
* So I think if there is any issue here, it is that pinned tabs behave differently, depending on whether or not you have the option for firefox to restore tabs on startup or not
* I don't know what pinned tabs are SUPPOSED to do though (are they intended to restore session cookies always? That would seem to subvert the web, and defeat the whole purpose of session cookies)

In the short term, the workaround is: IF you want to remain logged into gmail, set your default home page options to "Show my windows and tabs from last time". (and don't use containers for multiple gmails until bug bug 1283709 is fixed)


Testing results on Nightly:

C?	SR?	Pinned?	work?	Result?
no	no	no	yes	Not logged in
no	no	yes	yes	Not logged in
no	yes	no	yes	Logged in
no	yes	yes	yes	Logged in
yes	no	no	yes	Not logged in
yes	no	yes	yes	Not logged in
yes	yes	no	yes	Logged in
yes	yes	yes	yes	Logged in
yes	no	no	no	Not logged in
yes	no	yes	no	Not logged in
yes	yes	no	no	Logged in
yes	yes	yes	no	Logged in

Comment 21

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Actually I just tested pinning https://misuse.co/containers/cookies.html, and then restarting _without_ session restore. Session cookie for the pinned tab IS actually restored. So I am not sure why the 'partially logged out' behavior occurs for Mozilla gmail per the results from the previous comment. 

Whatever the reason though, it is NOT due to pinned tabs not restoring their cookies, since in testing this in isoloation, pinned tabs DO restore session cookies, even with containers enabled. So i am going to close this as invalid, assuming that the original issue was actually 1283709, which is not pinned tab specific.

Comment 22

[Dave Townsend [:mossop]]

Despite bug 1283709 being fixed I am still seeing the original problem in today's nightly.

Comment 23

[Tanvi Vyas[:tanvi]]

Kamil, can you take another look at this with an updated Nightly?  Thanks!

Comment 24

[Jonathan Hao (inactive) [:jhao]]

I think Paul closed this bug because cookies are not lost. But something must be wrong with gmail and okta. Perhaps we should change the bug summary.

Comment 25

[Tanvi Vyas[:tanvi]]

Its unclear if this is for all pinned tabs or pinned container tabs.  And yes, it may also have to do with a gmail/okta bug.

Comment 26

[Kamil Jozwiak [:kjozwiak]]

I think we're seeing this issue due too how okta treats session cookies in combination with how Gmail behaves. From the okta API documentation, it looks like session cookies expire when:

* session cookies expire (I believe it's 12 hours)
* the user logs out from the session
* the user closes the UA/browser (this case)

[1] http://developer.okta.com/docs/api/resources/sessions#session-cookie

Gmail account using okta:

* pinned tab using default container - Reproduced (session ended, was logged out)
* pinned tab using the personal container - Reproduced (session ended, was logged out)

Gmail account using Google's 2FA (no okta):

* pinned tab using default container - Can't Reproduced (was still logged into account)
* pinned tab using the personal container - Can't Reproduced (was still logged into account)

Comment 27

[Tanvi Vyas[:tanvi]]

This bug is not a containers bug.  It probably doesn't belong in Dom:Security.  It seems like an okta issue.  Using [domsecurity-*] so that it gets caught by triage.

Comment 28

[Tanvi Vyas[:tanvi]]

I'd like to revisit this because I've received two reports about this today in relation to containers.

Kamil, here is a somewhat exhaustive list of test cases, with okta gmail (work gmail) only, not non-okta gmail.  You don't have to go through all the test cases if you feel you have found the culprit, then you can stop testing all the various combinations listed below.

Set restore previous tabs to true in about:preferences
1) Open a regular tab.  Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
2) Open a work container tab.  Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
3) Open a regular tab.  Pin it.  Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
4) Open a work container tab.  Pin it. Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
5) Have 2 pinned tabs (in the default container) in a browser window to non-google sites.  Open another regular tab (unpinned). Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
6) Have 2 pinned tabs (in the default container) in a browser window to non-google sites.  Open a work container tab (unpinned). Login to okta gmail.  Restart the browser.  The tab should restore.  Are you still logged in?
7) Repeat 5 and 6, except where one of the two pinned tabs is a work container pinned tab.
8) Repeat 5, 6, 7, except where one of the two pinned tabs is a google site.

Comment 29

[Kamil Jozwiak [:kjozwiak]]

It looks like this is happening when you're logged into a Google okta account with both a container and a default container. I went through all the test cases from comment#28 and couldn't reproduce the problem until I logged into my Google okta account via the default container. Once I restarted fx, all container sessions were logged out. I tried different Google applications such as Calendar/Photos/Drive and ended up reproducing the same problem.

Example Test Case: (tested with pinned tabs as well and received the same results)

* install a fresh copy of the latest m-c
* log into gmail via okta using the personal container
* log into gmail via okta using the work container
* restart fx several times (10 times in my case)
* you'll still be logged into both instances when the tabs are restored
* log into gmail via okta using a default container
* restart fx
* you'll be logged into the default container but logged out of both the personal and work containers when the tabs are restored

Using the above test case, sometimes you'll still be logged into all three sessions during the first restart. However, any restart after that will log you out from both the personal and work containers, but keep you logged in within the default container.

I couldn't reproduce this when using my personal Gmail account with 2FA so I'm assuming it has something to do with how okta behaves with container sessions.

Test Case Results:
==================

Using the following build:
* fx51.0a1, buildId: 20160919030422, changeset: f0f15b7c6aa7
* https://archive.mozilla.org/pub/firefox/nightly/2016/09/2016-09-19-03-04-22-mozilla-central/

> Set restore previous tabs to true in about:preferences

Went into about:preferences#general and changed the following:
* When Nightly starts -> Show my windows and tabs from last time

> 1) Open a regular tab.  Login to okta gmail.  Restart the browser.  The tab
> should restore.  Are you still logged in?

Restarted the browser several times and was still logged into the okta gmail account.

> 2) Open a work container tab.  Login to okta gmail.  Restart the browser. 
> The tab should restore.  Are you still logged in?

Restarted the browser several times and was still logged into the okta gmail account.

> 3) Open a regular tab.  Pin it.  Login to okta gmail.  Restart the browser. 
> The tab should restore.  Are you still logged in?

Restarted the browser several times and was still logged into the okta gmail account.

> 4) Open a work container tab.  Pin it. Login to okta gmail.  Restart the
> browser.  The tab should restore.  Are you still logged in?

Restarted the browser several times and was still logged into the okta gmail account.

> 5) Have 2 pinned tabs (in the default container) in a browser window to
> non-google sites.  Open another regular tab (unpinned). Login to okta gmail.
> Restart the browser.  The tab should restore.  Are you still logged in?

Logged in and pinned both Facebook and Twitter. Restarted the browser several times and was still logged into the okta gmail account.

> 6) Have 2 pinned tabs (in the default container) in a browser window to
> non-google sites.  Open a work container tab (unpinned). Login to okta
> gmail.  Restart the browser.  The tab should restore.  Are you still logged
> in?

Logged in and pinned both Facebook and Twitter. Restarted the browser several times and was still logged into the okta gmail account.

> 7) Repeat 5 and 6, except where one of the two pinned tabs is a work
> container pinned tab.

Logged in and pinned both LinkedIn (Work container) and Twitter (default container). Restarted the browser several times and was still logged into the okta gmail account.

Comment 30

[Tanvi Vyas[:tanvi]]

Given Kamil's analysis, this 
1) has nothing to do with pinned tabs
2) shows that separation between container types (ex: work and personal) works fine
3) shows that separation between the default container and non-default containers is somehow broken.
4) is only reproducible with okta google accounts.

Maybe this has to do with cases where we force the usercontextId to 0.  The only such case I can think of though is Permissions, but Kamil didn't grant any special permissions when running these test cases.  Where else do we force the usercontextid to 0?  baku, do you have time to look into this?  Note that you have to set the browser to "Show my windows and tabs from last time".

Comment 31

[Marco Castelluccio [:marco]]

I am able to reproduce even if I login with the work container and another device (my phone). Maybe Okta is logging you out when you perform the login on another device, and to Okta's eyes there's no difference between two different containers and two different devices.

Comment 32

[Tanvi Vyas[:tanvi]]

(In reply to Marco Castelluccio [:marco] from comment #31)
> I am able to reproduce even if I login with the work container and another
> device (my phone). Maybe Okta is logging you out when you perform the login
> on another device, and to Okta's eyes there's no difference between two
> different containers and two different devices.

Thanks for the clue Marco!  Maybe we should try this on two browsers on the same computer (both two instances of the same browser so they have the same user agent and different browsers).  This doesn't explain why Kamil is able to stay logged into okta in both the Personal and Work container though.

Comment 33

[Marco Castelluccio [:marco]]

I'm able to stay logged in in both devices, but I get logged out from the first device when I restart the browser.

Comment 34

[Andrea Marchesini [:baku]]

Attachment: session.patch

nsICookieManager2.cookieExists ignores originAttributes. This patch is about this.
The main issue here is that we can not retrieve originAttributes from nsICookie because it could be implemented in JS and the getter of OA is marked as [implicit_jscontext].
What I propose here, is:
1. an optional originAttributes in cookieExists (similar to add() and remove()).
2. if this param is not passed. Then we try to retrieve originAttributes from the cookie (ignoring if the getter fails).

Comment 35

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8795407 [details] [diff] [review]
session.patch

>@@ -71,21 +71,33 @@ interface nsICookieManager2 : nsICookieM
>                      in int64_t     aExpiry,
>                      in NeckoOriginAttributesPtr aOriginAttributes);
> 
>   /**
>    * Find whether a given cookie already exists.
>    *
>    * @param aCookie
>    *        the cookie to look for
>+   * @param aOriginAttributes
>+   *        nsICookie2 contains an originAttributes but if nsICookie2 is
>+   *        implemented in JS, we can retrieve its originAttributes because the
s/can/can't/

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/885e361d4c73
nsICookieManager2.cookieExists must use the originAttributes, r=smaug

Comment 37

[Carsten Book [:Tomcat]]

seems this caused a xpshell bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=36609712&repo=mozilla-inbound

Comment 38

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1af5eb35bc34
Backed out changeset 885e361d4c73 for xpcshell bustage

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/826cc48624a3
nsICookieManager2.cookieExists must use the originAttributes, r=smaug

Comment 40

[Carsten Book [:Tomcat]]

sorry had to back this out for crashes like https://treeherder.mozilla.org/logviewer.html#?job_id=36715829&repo=mozilla-inbound

Comment 41

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/98eb59193369
Backed out changeset 826cc48624a3 for windows m-oth and xpc crashes

Comment 42

[Andrea Marchesini [:baku]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8be0d91bf0e&selectedJob=28266820

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9cba6697ae68
nsICookieManager2.cookieExists must use the originAttributes, r=smaug

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ae01933b95a
nsICookieManager2.cookieExists must use the originAttributes - part 2, r=me

Comment 45

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9cba6697ae68
https://hg.mozilla.org/mozilla-central/rev/5ae01933b95a

Comment 46

[Kamil Jozwiak [:kjozwiak]]

Went through verification using the following build:
* https://archive.mozilla.org/pub/firefox/nightly/2016/10/2016-10-12-03-02-11-mozilla-central/

I spent a good amount of time going through all the different test cases outlined throughout this bug and I couldn't reproduce the original issues. I went through the following cases:

* comment#6
* comment#7
* comment#28

Platforms Used:

* macOS 10.12 x64 - didn't run into any issues restoring sessions
* Win 10 x64 VM - didn't run into any issues restoring sessions
* Ubuntu 16.04 LTS x64 VM - didn't run into any issues restoring sessions

Some other cases used from the smoke tests SV runs via TestRails:

* ensured m-c is being restored correctly when
** restarting fx during an add-on installation
** restarting fx after a crash (http://ted.mielczarek.org/mozilla/crashme.html)
** restoring via "History -> Recently Closed Tabs"

Dave, would you mind quickly checking if your original test case has been fixed as well?

Comment 47

[Dave Townsend [:mossop]]

This is working for me now, thanks

Comment 48

[Kamil Jozwiak [:kjozwiak]]

(In reply to Dave Townsend [:mossop] from comment #47)
> This is working for me now, thanks

Awesome, thanks for checking Dave :)