session lost after restart

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: mozilla, Assigned: dwitte)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100118 Ubuntu/10.04 (lucid) Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100118 Ubuntu/10.04 (lucid) Minefield/3.7a1pre

what I'm seeing is sites that usually didn't logout before (early chromium-dev/chromium 3, FF 3.5.x), now (current Chromium dev, FF 3.6, and 3.7) loose logins even if Remember Me box is selected
but haven't managed to put my finger on it yet, its one of those "I have this strange feeling this wasn't like this before" cases, and a coworker (who just upgraded his mac to firefox 3.6) just mentioned the same, reforcing my beliefs.

sites like gmail, identica, etc

Reproducible: Sometimes

Steps to Reproduce:
1. open gmail.com, login with Remember Me.
2. close browser
3. open gmail again
Actual Results:  
asks for login

Expected Results:  
to be logged in

[reed] in IRC suggested to enable NSPR logging for cookies, but I dont know how.
(Reporter)

Comment 1

9 years ago
to get debug
$export NSPR_LOG_MODULES=all:5
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
(Assignee)

Comment 3

9 years ago
sdwilsh, see previous comment.
My guess would be that we are treating something as a session cookie when we shouldn't be.  Do you have one site it always happens on?
(Reporter)

Comment 5

9 years ago
not always, but then again i havent use FF so intensive to notice so!
i'll try it a bit this weekend to see
I see it reliably on livejournal.com (that's what I used to find the regression range).

I may have seen it on some other sites, but I don't remember what they were. If I run into them again, I'll make note of them here.

Comment 7

9 years ago
Same problem here, with all sites, including major social networks such as Facebook and Twitter as well as Google sites. Another example are WordPress blogs.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a4pre) Gecko/20100327 Minefield/3.7a4pre
There could be different problems here. The initial reporter said he sees the problem in 3.6 also, but the regression range in comment 2 doesn't include anything fixed in 3.6 (or even 3.6.2; one privacy mode bug that will be fixed in 3.6.3).

The initial reporter also sees a problem with Chromium which has nothing in common with  Firefox, so that might be a system issue.

Comment 7 is seeing it with all sites, earlier commenters only on some. We do know in the past that corruption in the cookies.sqlite file sometimes resulted in the inability to save any cookies. If it's that kind of problem it makes some sense that some people see it and others can't reproduce. In that case it might be hard to figure out what caused the initial corruption.

(In reply to comment #1)
> $export NSPR_LOG_MODULES=all:5

That's not terribly useful. That will include all debugging output from every part of the product and what we're looking for will be painful to pick out from the noise. If possible it's better to turn on logging for the most narrow set of modules.
(Reporter)

Comment 9

9 years ago
(In reply to comment #8)
> The initial reporter also sees a problem with Chromium which has nothing in
> common with  Firefox, so that might be a system issue.

I did more tests on chromium, and cant reproce as easy as FF.
From what I can see, what I was seeing in chromium was mostly related to the change Google as been dealing with cookies and sessions on their site, ie, expiring after two weeks, for security reasons.

Comment 10

9 years ago
(In reply to comment #8)

> Comment 7 is seeing it with all sites, earlier commenters only on some. We do
> know in the past that corruption in the cookies.sqlite file sometimes resulted
> in the inability to save any cookies. If it's that kind of problem it makes
> some sense that some people see it and others can't reproduce. In that case it
> might be hard to figure out what caused the initial corruption.

Recreating cookies.sqlite for an existing profile and using a new profile did not solve the problem.

The cookies are listed in the cookie manager.

Please let me know if/how I can provide (more) useful information on this issue.
In addition to http://livejournal.com, I'm also losing cookies from http://boards.theforce.net

After logging in, I can go to the cookies GUI and it looks like they have proper expiration dates. However, when I restart, the cookies are gone.

Also, after closing Firefox and checking the contents of the cookies.sqlite, it looks like some of the cookies from these sites are not being written to it.

So this appears to backup sdwilsh in Comment 4.

Comment 12

9 years ago
I can reproduce the issue on all sites, i.e. I have to login again and again after each browser restart, it seems not to be a site-specific issue.

Comment 13

9 years ago
I'd like to add, i'm seeing this issue with the minefield nightly also.
Over the last week or two, i lose sessions on seemingly random sites after a restart. I cannot detect any noticeable pattern to it, and it affects all types of sites including Facebook,Reddit,assorted Vbulletin forums,phpBB boards,Google and Windows live etc.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100409 Minefield/3.7a5pre ID:20100409040127
(Assignee)

Comment 14

9 years ago
I've heard multiple reports of what Rob's saying in comment 13. There have been no changes in cookie code recently.

This is probably a bug in either storage, or sessionstore. sdwilsh, zpao, have there been any changes there recently?
Bug 536978 looks to be the most recent changes to the cookies service, and it's within the regression range I found.

Would it be possible to get a tryserver build with Bug 536978 backed out? I'm curious to see if that will help anyone.
(Assignee)

Comment 16

9 years ago
Builds are here: https://build.mozilla.org/tryserver-builds/dwitte@mozilla.com-try-0a84351b59b5/

I didn't think that change could be responsible since people have been seeing this just over the last week or so, but maybe it is!

Comment 17

9 years ago
Forgive my ignorance here, is this a build i can test over a few days?
I assume it won't just update and overwrite the test build when a new nightly is out?
Happy to run it and report back if so.
Thanks.
After some preliminary testing (login to problem sites, restart a few times), the tryserver build looks to have fixed the problem I was having.
(Assignee)

Comment 19

9 years ago
(In reply to comment #17)
> Forgive my ignorance here, is this a build i can test over a few days?

Correct.

Comment 20

9 years ago
The tryserver build appears to have fixed the issue.
48 hours of average use, and still holding the sessions on all my regular sites after multiple restarts.

Comment 21

9 years ago
Same here, the problem is no longer reproducible.
(Assignee)

Comment 22

9 years ago
Shawn, can you debug and see if you can reproduce this?

Comment 23

9 years ago
(In reply to comment #21)
> Same here, the problem is no longer reproducible.

Being more precise, re-starting the browser does no longer cause a loss of session data, however, updating and re-starting the browser has still the same effect.
AFAIK the hourly/tryserver builds are on the nightly channel, so updating the browser will just update you to a version that has the bug.

Comment 25

9 years ago
(In reply to comment #24)
> AFAIK the hourly/tryserver builds are on the nightly channel, so updating the
> browser will just update you to a version that has the bug.

Thanks for your clarification, with Dan Witte's trybuild, the above-described problem is indeed no longer reproducible.
Blocks: 536978
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Assignee: nobody → sdwilsh
I'm having a very hard time reproducing this (as in, I can't).  Can somebody provide me with steps to reproduce?  I can't fix this without them.

Comment 27

9 years ago
I updated back to the trunk last night after running the tryserver build for 5 days without any issues, but.....
So far, the nightly seems to be free of this problem now.

Is it possible something was modified over the last 4 or 5 days on the trunk build to affect this issue?

Previously, the steps to reproduce were..
Tick 'remember me' & log in to a website or forum. Close tabs.
Restart minefield, & upon revisiting previous website/forum you will have to log in again approx 7 out of 10 attempts at recreating the issue.
STR:
1. Create new profile
2. Login to problematic site (remember to check 'remember me' or 'auto login')
3. Restart Firefox
4. Visit site from #2

The problem is that this seems to be affecting people differently. For me this only seems to affect http://livejournal.com and http://boards.theforce.net but others see it on different/all sites.

@Rob, still seeing problems on trunk.

Comment 29

9 years ago
Ok, Upon restarting the trunk from a fresh boot this morning, it appears to have lost sessions on all my common sites...phpBB,Vbulletin,IPB,gmail etc...

Please disregard my previous comment.

Comment 31

9 years ago
The problem is still reproducible, i.e. sessions are lost after restart.

Comment 32

9 years ago
This issue rectified itself about 2 weeks back, for me at least.
Sessions are now held.
(Assignee)

Comment 33

9 years ago
I'm going to post a tryserver build sometime soon, with extra logging, for those willing to test. Hopefully that'll give some more info.
(Assignee)

Comment 34

9 years ago
Found two problems by code inspection:

a) BindParameters is never called in AddCookieToList: http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/src/nsCookieService.cpp#2920

b) In AddInternal, we can call RemoveCookieFromList followed by AddCookieToList. The former is unbatched, the latter is. Which means operations can get out-of-order.

I'm not sure if these are resulting in the problems here, but we can fix and test.
(Assignee)

Comment 35

9 years ago
Created attachment 445996 [details] [diff] [review]
Part 1: Fix AddCookieToList
Assignee: sdwilsh → dwitte
Attachment #445996 - Flags: review?(sdwilsh)
(Assignee)

Comment 36

9 years ago
Created attachment 445997 [details] [diff] [review]
Part 2: Don't batch in AddInternal
Attachment #445997 - Flags: review?(sdwilsh)
Comment on attachment 445996 [details] [diff] [review]
Part 1: Fix AddCookieToList

Ugh.  I looked at this method for a good half hour when I was looking at this and didn't spot this.

Can we write a test that would have caught this by chance?

r=sdwilsh
Attachment #445996 - Flags: review?(sdwilsh) → review+
(Assignee)

Updated

9 years ago
Duplicate of this bug: 567479
Comment on attachment 445997 [details] [diff] [review]
Part 2: Don't batch in AddInternal

r=sdwilsh
Attachment #445997 - Flags: review?(sdwilsh) → review+
(Assignee)

Comment 40

9 years ago
Comment on attachment 445996 [details] [diff] [review]
Part 1: Fix AddCookieToList

http://hg.mozilla.org/mozilla-central/rev/f318846e8ee3

Should be in last night's nightly; I'll push the second part today. (Want to have separation here, for debugging purposes.)
(Assignee)

Comment 41

9 years ago
Comment on attachment 445997 [details] [diff] [review]
Part 2: Don't batch in AddInternal

http://hg.mozilla.org/mozilla-central/rev/5e3a1f437674

Which will be in today's nightly.
(Assignee)

Comment 42

9 years ago
Martin, Rob: Could you guys test with tonight's nightly? (So, download/update tomorrow, and you should get it.)

If you've been having this problem recently, and it goes away with the new nightly, then I think we've fixed this one.
Looks fixed to me. The sites that were giving me problems no longer are.
(Assignee)

Comment 44

9 years ago
Awesome. Please reopen if you see any more problems.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.