Closed Bug 1503757 Opened 11 months ago Closed 11 months ago

Session times out quickly in Nightly

Categories

(Core :: Networking: Cookies, defect, P1, blocker)

65 Branch
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
mozilla65
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 blocking verified

People

(Reporter: nmanole, Assigned: jkt)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Go to http://forum.pimaxvr.com/c/pimax-8k
- while logged in, visit forum topics
- after a minute or two, notice that you are no longer logged in

Build ID: 20181031223503
Version: 65.0a1




Actual results:

I was logged out of my session, without any action on my part.


Expected results:

I should have remained logged in. Did not notice this behavior two or so Nightly versions ago, with this site.
When trying to submit this bug, the session timeout happened right on this site, and I had to re-login in order to finish the submission.
I’m seeing this. Not sure if it’s container related but I’m losing all cookies... I have to prove my identity to Google and Lastpass multiple times. I currently suspect Bug 1472212 but that’s a guess. Nightly is currently unusable for me.
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm also experiencing this with tabs that are in the default container - I got logged out of Twitter, Gmail (personal and work) and Reddit.
I'm experiencing this bug too.  gmail/facebook/twitter/Bugzilla. Even disable all the extensions.
Viewing cookies ("Manage Data..."), I now have 0 cookies for every site.  Hopefully the Bugzilla cookie sticks around long enough to post this...
I'm also logged out of Sync, which I assume is not using cookies. Maybe Ehsan has some ideas.
Component: Untriaged → Networking: Cookies
Flags: needinfo?(ehsan)
Priority: -- → P1
Product: Firefox → Core
Sync is fine for me.  So cookies seems right.
I opened and signed in to all of the sites Mike mentioned in comment 3 and was not signed out. My Treeherder, Bugzilla, Personal Gmail, Twitter, and Reddit accounts all stayed signed in.

Until I opened a container tab and signed in to my work Gmail there as well. Then Treeherder and Bugzilla lost my login.

For some reason, both Gmails, Twitter, and Reddit are still signed in.

I see this in the error console: IndexedDB UnknownErr: ActorsParent.cpp:13774
Which points to https://searchfox.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#13774.

That may be unrelated, though.

I'm also unable to reproduce this a second time. I signed back in to the sites that I was signed out of, and I opened a new container tab (into a previously unused container), and signed in to another Reddit account, but I'm still signed in for all of my open tabs across all of these sites...
Duplicate of this bug: 1503782
Interestingly my desktop notification settings for Skype for Web got lost while I still remained logged in.

I suspect further bug reports don't help but just in case, I've been signed out of: Gmail (2x), Bugzilla (3~4x), Twitter, four instances of Slack, IRCCloud, and Skype for Web. All lost their desktop notification settings. I don't use containers.
Possible regression window 

16:08.19 INFO: Narrowed inbound regression window from [13d1718b, e28fa79b] (4 builds) to [64c0da93, e28fa79b] (2 builds) (~1 steps left)
16:08.19 INFO: No more inbound revisions, bisection finished.
16:08.19 INFO: Last good revision: 64c0da939880dc9fd8416f63ace57590b6d26230
16:08.19 INFO: First bad revision: e28fa79bc2f94ca3b72456b47353f2e2dda8da1a
16:08.19 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=64c0da939880dc9fd8416f63ace57590b6d26230&tochange=e28fa79bc2f94ca3b72456b47353f2e2dda8da1a
Ryan, could your RuntimeService::Cleanup() change for bug 1501196 be causing session cookies to time out too soon?
Blocks: 1501196
Flags: needinfo?(rhunt)
OS: Unspecified → All
I am seeing this too on one machine, where I am logged out of every site (Twitter, Mastodon/Pinafore), an Open-Xchange instance, and others, at every browser restart. Also, the Threema Web (https://web.threema.ch) session gets blown away, which is also LocalStorage, not just cookies.

A second machine, the one I am on now, doesn't experience this. There, the session remains intact even through a Windows Insider update restart.
Let's back out bug 1501196 on suspicion. This will take a while for people to confirm on Nightly and we're causing some serious frustrations right now.
Flags: needinfo?(ryanvm)
Bug 1501196 has been backed out from central and new nightlies have been requested.
Flags: needinfo?(ryanvm)
I'm finding this issue to be very frustrating and disruptive - probably the worst I've seen on Nightly since I started testing.

Can we put a halt on rolling out nightly builds until new builds are spinned? No need to put others through this.
Duplicate of this bug: 1503820
Received the first Nightly of the day ~30 minutes ago. This issue seems to be gone on build 20181101100640.
I am also seeing this. It took a while longer than before, but everything still signed out at the same time.
It sounds like we've got a few more potential regressors identified, and new Nightly's are spinning, so that's good.

In the event that we need more diagnostic data to solve this, one thing I've also noticed that _might_ be related is that if I try to restart the browser by opening the Browser Console and hitting Cmd-Shift-R, the main process hangs and eventually crashes.

Here are some crash reports for those:

https://crash-stats.mozilla.com/report/index/7394ff1c-3a4c-41c0-86ec-41d620181101
https://crash-stats.mozilla.com/report/index/b3dfd510-4f25-4b85-b660-21b250181101

looks like mozilla::dom::quota::QuotaManager::ShutdownObserver::Observe ?

Unsure if it's related, but QuotaManager does exist in the realm of storage, and I started to see these restart crashes right around the time I was getting logged out. Just wanted to add a datapoint.
I can also reproduced on Nightly65.0a1(Build ID 20181101100640) cset 3cff4bff1c9d8e65e73a966fe09c4e5aa1ed734a.
tested facebook, twitter , and BMO.

And I get a same regression window of Comment 22.
Duplicate of this bug: 1503873
Looks like the regression was unrelated to cookie manager, clearing my needinfo.  Thanks everyone for figuring it out so quickly.
Flags: needinfo?(ehsan)
I've also noticed the problem can occur if you restart an instance (if you need something a bit sooner than just wait for the clock to tick down.) Disabling tracking seems to be a work around.
(In reply to JR Conlin [:jrconlin,:jconlin] from comment #29)
> Disabling tracking seems to be a work around.

I'm still being logged off with tracking disabled in Build-ID 20181101100640 (unless you are referring to something other than about:preferences#privacy and unchecking "!! Trackers").
I've also managed to reproduce this issue with a new clean profile:
1. Fire up Nightly.
2. Login to gmail.com
3. Wait 10-20'.

AR:
You are logged out of the gmail session.

To somehow confirm comment 29, seems like browser console throws:

Request to access cookie or storage on “https://accounts.google.com/o/oauth2/postmessageRelay?parent=https%3A%2F%2Fdavidwalsh.name&jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.en_US.r3VEB-hu6dk.O%2Fam%3DQQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAGLTcCPdzfaDsFYsZF5Fx6dxuyMdlAHKvg%2Fm%3D__features__#rpctoken=768645999&forcesecure=1” was blocked because it came from a tracker and content blocking is enabled.
2679293615-postmessagerelay.js:6:50
uncaught exception: CustomError: Error in protected function: [object Object]
Empty string passed to getElementById(). m=sps,spl,spit,m_i,spt,t,it:444:246
Request to access cookie or storage on “https://accounts.google.com/o/oauth2/postmessageRelay?parent=https%3A%2F%2Fdavidwalsh.name&jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.en_US.r3VEB-hu6dk.O%2Fam%3DQQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAGLTcCPdzfaDsFYsZF5Fx6dxuyMdlAHKvg%2Fm%3D__features__#rpctoken=768645999&forcesecure=1” was blocked because it came from a tracker and content blocking is enabled.
Duplicate of this bug: 1503958
I saw:
[Child 10730, Main Thread] WARNING: '!topLevelStoragePrincipal', file /home/jonathan/projects/mozilla-unified/toolkit/components/antitracking/AntiTrackingCommon.cpp, line 85

On a debug build with my patch in that got backed out. I'm seeing if I can reproduce again a few times. I have witnessed http://www.html-kit.com/tools/cookietester/ clearing it's cookies.
Build-ID 20181101151140 fixed the issues I was having since last night.

Thank you!
Respins are finished and we have multiple confirmations that the issue is resolved by the latest backout.
Assignee: nobody → jkt
Blocks: 1490257
No longer blocks: 1501196
Status: NEW → RESOLVED
Closed: 11 months ago
Flags: needinfo?(rhunt)
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Status: RESOLVED → VERIFIED
Has Regression Range: --- → yes
Has STR: --- → yes
(In reply to Jonathan Kingston [:jkt] from comment #33)
> I saw:
> [Child 10730, Main Thread] WARNING: '!topLevelStoragePrincipal', file
> /home/jonathan/projects/mozilla-unified/toolkit/components/antitracking/
> AntiTrackingCommon.cpp, line 85

If the antitracking component is tripping things over, please set MOZ_LOG to AntiTracking:5 to capture a log and file a follow-up and ni? with the log.  Thanks!
Duplicate of this bug: 1503784
We have verified the issue is no longer reproducible on Windows 10 x64 and Ubuntu 18.04 using the latest Nightly build (20181101151140).
I'm seeing reports that this issue is no longer reproducible but I'm getting the same problem.
Duplicate of this bug: 1504097
Duplicate of this bug: 1504084
I am still having the issue in Windows 7, Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0,  	Windows_NT 6.1  20181101220058
Duplicate of this bug: 1504269
I am still having the issue in Windows 7, Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0,  	Windows_NT 6.1 Build 20181104100118.
Duplicate of this bug: 1503696
Hi Tania! Is anybody from SoftVision able to reproduce the described issue using the 20181101220058 build?
Flags: needinfo?(tmaity)
Hi Mike,
We are looking into this and will have an update shortly.
Flags: needinfo?(tmaity)
(In reply to Mike Conley (:mconley) (:⚙️) from comment #46)
> Hi Tania! Is anybody from SoftVision able to reproduce the described issue
> using the 20181101220058 build?

The issue is not reproducible with 65.0a1 20181101220058 on Ubuntu 16.04/ Windows 10.
(In reply to Gabriela [:gaby2300] from comment #44)
> I am still having the issue in Windows 7, Mozilla/5.0 (Windows NT 6.1;
> Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0,  	Windows_NT 6.1 Build
> 20181104100118.

Are there particular sites you're seeing this on?
Flags: needinfo?(gmontagu)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #49)
> (In reply to Gabriela [:gaby2300] from comment #44)
> > I am still having the issue in Windows 7, Mozilla/5.0 (Windows NT 6.1;
> > Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0,  	Windows_NT 6.1 Build
> > 20181104100118.
> 
> Are there particular sites you're seeing this on?

Yes, all sites where I have to login even with Nightly set to remember passwords: gmail, Pontoon, bugzilla, Facebook, Twitter, Mozilla Reps.
Flags: needinfo?(gmontagu)
(In reply to Gabriela [:gaby2300] from comment #50)
> Yes, all sites where I have to login even with Nightly set to remember
> passwords: gmail, Pontoon, bugzilla, Facebook, Twitter, Mozilla Reps.

Yikes, okay. If you create a new profile, and log in to one or more of those accounts, do you still see the same issue?
Flags: needinfo?(gmontagu)
The replication I was seeing on a debug build was:

1. Create a clean profile
2. Add a cookie here: http://www.html-kit.com/tools/cookietester/
3. Wait about 10 minutes
4. Debug loggs of the following show up:
[Parent 21221, Main Thread] WARNING: 'NS_FAILED(rr->RetargetDeliveryTo(sts))', file /home/jonathan/projects/mozilla-unified/dom/fetch/FetchDriver.cpp, line 1076
5. Refresh the page


My hunch is this might be related to:
Services.obs.notifyObservers(null, "clear-origin-attributes-data", JSON.stringify({ userContextId: undefined }));


This permits a undefined userContextId which my patch I think was doing, there doesn't seem to be other active call sites that would cause this though. I replicated calling this and clearing the cookies.
Depends on: 1504782
(In reply to Mike Conley (:mconley) (:⚙️) from comment #51)
> (In reply to Gabriela [:gaby2300] from comment #50)
> > Yes, all sites where I have to login even with Nightly set to remember
> > passwords: gmail, Pontoon, bugzilla, Facebook, Twitter, Mozilla Reps.
> 
> Yikes, okay. If you create a new profile, and log in to one or more of those
> accounts, do you still see the same issue?

I'll try and I'll let you know. I'll have to wait for the new update though.
Okay, thank you gaby2300 - and sorry this is still affecting you. :/
Maybe I should have added that I face the issue every time I open Nightly. I don't get signed out during sessions.
Flags: needinfo?(gmontagu)
(In reply to Gabriela [:gaby2300] from comment #55)
> Maybe I should have added that I face the issue every time I open Nightly. I
> don't get signed out during sessions.

This does not sound like the same issue.

Perhaps something related to getting history cleared on exit.
(In reply to Caspy7 from comment #56)
> (In reply to Gabriela [:gaby2300] from comment #55)
> > Maybe I should have added that I face the issue every time I open Nightly. I
> > don't get signed out during sessions.
> 
> This does not sound like the same issue.
> 
> Perhaps something related to getting history cleared on exit.

Is this possible without having the pref enabled?
(In reply to Gabriela [:gaby2300] from comment #57)
> (In reply to Caspy7 from comment #56)
> > (In reply to Gabriela [:gaby2300] from comment #55)
> > > Maybe I should have added that I face the issue every time I open Nightly. I
> > > don't get signed out during sessions.
> > 
> > This does not sound like the same issue.
> > 
> > Perhaps something related to getting history cleared on exit.
> 
> Is this possible without having the pref enabled?


Please disregard my earlier comment, the issue seems to be fixed now. 
Should it reappear, I will add another comment here.
(In reply to Gabriela [:gaby2300] from comment #58)
> Please disregard my earlier comment, the issue seems to be fixed now. 
> Should it reappear, I will add another comment here.

Great, thanks!
You need to log in before you can comment on or make changes to this bug.