1403737 - All sessions can be invalidated on upgrade

Status: NEW

(Firefox :: Session Restore, defect, P2)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

I ran an update from 56 Beta (last RC) to 57 Beta. On relaunch my tabs were restored as expected but all session state information was invalidated requiring that I re-authenticate with GMail, Google Apps, Trello, Twitter, etc. as well as Pocket.

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

Not sure if this is a pervasive issue. If it is, I think this should track 57 as the user experience of having all session information invalidated is not good.

Marking as a regression as I did not have this issue with previous Beta updates.

Comment 2

[Mike de Boer [:mikedeboer]]

I've had different upgrade issues, with another cause... What I'm thinking of when I read comment 0 is that your session cookies were somehow wiped/ not restored. And the most invasive change in 57 in that regard is bug 1331680.
Amy, is it possible that your work could have somehow caused this?

Comment 3

[Amy Chung [:Amy]]

Hi Mike,
I tried to update 56 beta to 57 beta, and the reproducing steps as below:
1. Login to facebook on Firefox 56 beta.
2. Updated 56 beta to 57 beta.
3. The facebook still in the login status.

And bug 1331680 doesn't process session restore and the cookies which are store into db.
In my view, the bug 1331680 doesn't occur the problem on this bug.

Would you offer me your reproducing steps and this problem would occur on every updating time?

Thanks!

Comment 4

[Mike de Boer [:mikedeboer]]

Amy, thanks for looking and walking through it! As per the reasons you mentioned, I'm also quite confident that bug 1331680 is not the culprit here.

Comment 5

[Marcia Knous [:marcia]]

I am not sure it makes much sense to track this issue for 57 unless we can come up with additional evidence that is a systemic issue when users upgrade from 56->57. Probably the only way we will know this is if we do some focused testing around that upgrade path.

Comment 6

[Marcia Knous [:marcia]]

(In reply to Marcia Knous [:marcia - use ni] from comment #5)
> I am not sure it makes much sense to track this issue for 57 unless we can
> come up with additional evidence that is a systemic issue when users upgrade
> from 56->57. Probably the only way we will know this is if we do some
> focused testing around that upgrade path.

I entered a PI-request for some focused testing around this.

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracking "-" this as I haven't heard of any more instances of this problem. Hi Florin/Tom, please renominate for tracking if SV encounters this issue during the focused testing that Marcia requested.

Comment 8

[Oana Botisan, Desktop QA]

I tried to reproduce the bug using different versions of beta 56 and updating them to the last beta 57 on Mac OS X 10.11, macOS 10.12 and macOS 10.13, but I couldn't reproduce it. 

I tested this bug by login into gmail, Facebook and Twitter both with the same email address or different email addresses. 
On Mac OS X 10.11 - I both chose to save the passwords in the browser and not to save them and I updated from:
 - 56.0b1 to 56.0b3 to 57.0b8
 - 56.0b6 to 57.0b8
 - 56.0b12 to 57.0b8

On macOS 10.12 - I saved the passwords in the browser and I updated from:
 - 56.0b1 to 56.0b3 to 57.0b8
 - 56.0b7 to 57.0b8
 - 56.0b9 to 57.0b8

On macOS 10.13 - I chose not to save the passwords in the browser and I updated from:
 - 56.0b2 to 56.0b3 to 57.0b8
 - 56.0b3 to 57.0b8
 - 56.0b10 to 57.0b8

Every time the browser restarted, the session was kept and I was still logged in every account.

Comment 9

[Ethan Tseng [:ethan]]

Hi Will,

We heard some other people experienced this issue recently.
Can you help to investigate it?

Comment 10

[Will Wang [:WillWang]]

Hi Ethan :)

My first thought is same with what Mike said in comment 2, which is about session cookie - seems like all session cookies can not be used anymore.

Given that comment 3/5/7/8, I believe we need more info like STR to push this bug forward.
Do you know anyone who can share his/her own experience?

Besides,
With the new info, our QA team could help to provide the regression window in a more specific way.
Regression window can help a _lot_ to this bug, thus developers can look into those patches and find the possible culprit.

And it's also helpful to know the exact version of Firefox before/after the upgrade, however, the reporter's account had been disabled.
This could help our QA team to narrow down their testing space.

----
Hi Oana,

Could you help to reproduce/find the regression window again based on the new info?


Thank you!

Comment 11

[Oana Botisan, Desktop QA]

> Hi Oana,
> 
> Could you help to reproduce/find the regression window again based on the
> new info?
> 
> 
> Thank you!

If I had more information, maybe I could reproduce the bug and after that verify it.

But considering the nature of this bug and the fact that it requires an update, I am not sure how I could find a regression window. I guess it will all depend on the new information we get.

Comment 12

[Ethan Tseng [:ethan]]

(In reply to Will Wang [:WillWang] from comment #10)
> Hi Ethan :)
> Given that comment 3/5/7/8, I believe we need more info like STR to push
> this bug forward.
> Do you know anyone who can share his/her own experience?

Unfortunately, I don't know.  :(
Sylvestre said in a Slack channel (57triage-and-tracking) that his friends experienced this issue recently.

I don't think there will be a clear STR.  NI Sylvestre for confirmation.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Sure, how can they help?

Comment 14

[Ethan Tseng [:ethan]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #13)
> Sure, how can they help?

I don't think it's practical to ask our friends to downgrade and upgrade again to reproduce the bug.
I ping'ed you just to know if you have any detailed information about the scenario since we don't have clear steps for reproduction yet.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

I experienced it myself a few days ago too.

Comment 16

[:gerard-majax]

Just happened to me, nightly/linux, upgrading from yesterday's or this morning nightly to 20171130101246.

Comment 17

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #16)
> Just happened to me, nightly/linux, upgrading from yesterday's or this
> morning nightly to 20171130101246.

FTR, in my case, I could notice that:
 - any session opened in a tab with a specific context would be lost
 - session opened in a tab without a context would be kept intact

Comment 18

[Andrew Overholt [:overholt]]

Justin, can anyone take a look in Mike's absence?

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

I'm not able to reproduce this. In any case, too late to fix for 57. 
If we get clear STR, that might help. So far I haven't seen it.

Comment 20

[Justin Dolske [:Dolske]]

This is likely non-actionable without a reproducible STR, especially given the lack of other reports since this was filed.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

I experienced myself a few times too (linux nightly)

Comment 22

[:gerard-majax]

Attachment: stdout garbage

I got bitten by sessions being invalidated in the past, in a random way. This also seems to happen on a more recurring basis with just tabs informations, with `sessionstore.jsonlz4` being somehow corrupted (like 88K instead of 279K this morning).

After a few occurrences, I think I have spotted a pattern related to the reproduction of the issue. I'm running nightly (l10n fr), on ubuntu (17.10). Somehow, it seems the bug got reproduced much more frequently under those STRs:
 (1) run nightly (l10n ?) for a few days, T=0, T=1, T=2, T=3 with T=0 being the first day
 (2) let pending updates reboot accumulate, you should always have T=1 update pending a restart
 (3) on day #4 (fifth day), decide to apply the pending T=1 update, firefox restarts, applis update, and restores everything
 (4) immediately spots a new update pending notification asking to click to apply, do it. I have no idea which update that is in the ordering, but,
 (5) update applies, firefox restarts,

Now, what I see at this point:
 - lots of garbage in stdout, related to IPC failures (attached)
 - sessionstore.jsonlz4 is corrupted, tabs are not reloaded
 - I have to copy from sessionstore-backups/update.jsonlz4-xxx to recover

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Andrei, could you find someone who could test Alexandre's STR? Thanks!

Comment 24

[Mathieu Pillard [:mat]]

FWIW, I accidentally reproduced the issue with those STR, since that's how I tend to use nightly myself.

Comment 25

[Andrei Vaida [:avaida]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #23)
> Andrei, could you find someone who could test Alexandre's STR? Thanks!

Hi Sylvestre, just wanted to let you know that we are working on this (and have been for a few days) and we should have test results available soon. Leaving the ni? in place until our investigation is completed.

Comment 26

[Oana Botisan, Desktop QA]

I tried to reproduce this bug using the steps from comment 22 on Ubuntu 13.10 x64, Ubuntu 16.04 x32 and Ubuntu 17.10 (generated in VirtualBox), but I couldn't. The session was successfully restored even after the last update.

Comment 27

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like this is an uncommon problem. I'm letting it drop from regression triage.

Too late to fix in 59, but we can still take a patch in Nightly if 61 is affected.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 22 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 29

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.