Open Bug 1403737 Opened 4 years ago Updated 4 years ago

All sessions can be invalidated on upgrade

Categories

(Firefox :: Session Restore, defect, P2)

57 Branch
x86_64
macOS
defect

Tracking

()

Tracking Status
firefox57 - wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- fix-optional
firefox61 --- fix-optional

People

(Reporter: lmandel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

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.
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.
Keywords: regression
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Version: unspecified → 57 Branch
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?
Flags: needinfo?(amchung)
Priority: -- → P1
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!
Flags: needinfo?(amchung) → needinfo?(mdeboer)
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.
Flags: needinfo?(mdeboer)
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.
(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.
Priority: P1 → P2
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.
Flags: needinfo?(tgrabowski)
Flags: needinfo?(florin.mezei)
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.
Flags: needinfo?(tgrabowski)
Flags: needinfo?(florin.mezei)
Hi Will,

We heard some other people experienced this issue recently.
Can you help to investigate it?
Flags: needinfo?(wiwang)
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!
Flags: needinfo?(wiwang)
Flags: needinfo?(oana.botisan)
Flags: needinfo?(ettseng)
> 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.
Flags: needinfo?(oana.botisan)
(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.
Flags: needinfo?(ettseng) → needinfo?(sledru)
Sure, how can they help?
Flags: needinfo?(sledru) → needinfo?(ettseng)
(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.
Flags: needinfo?(ettseng)
I experienced it myself a few days ago too.
Summary: On upgrade from 56 Beta to 57 Beta all sessions were invalidated → All sessions can be invalidated on upgrade
Just happened to me, nightly/linux, upgrading from yesterday's or this morning nightly to 20171130101246.
(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
Justin, can anyone take a look in Mike's absence?
Flags: needinfo?(dolske)
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.
This is likely non-actionable without a reproducible STR, especially given the lack of other reports since this was filed.
Flags: needinfo?(dolske)
I experienced myself a few times too (linux nightly)
Attached file 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
Andrei, could you find someone who could test Alexandre's STR? Thanks!
Flags: needinfo?(andrei.vaida)
FWIW, I accidentally reproduced the issue with those STR, since that's how I tend to use nightly myself.
(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.
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.
Flags: needinfo?(andrei.vaida)
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.
You need to log in before you can comment on or make changes to this bug.