Closed Bug 1059074 Opened 10 years ago Closed 10 years ago

Cannot login to Google Accounts (says cookies not enabled)

Categories

(Web Compatibility :: Site Reports, defect)

defect
Not set
normal

Tracking

(firefox33 unaffected, firefox34+ verified, firefox35 verified)

VERIFIED FIXED
Tracking Status
firefox33 --- unaffected
firefox34 + verified
firefox35 --- verified

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: qablocker, regression, Whiteboard: spdy, workaround: comment 11)

Attachments

(2 files)

157.81 KB, application/x-bzip2
Details
3.55 MB, application/x-zip-compressed
Details
[Tracking Requested - why for this release]: regression

Steps To Reproduce:
1. Start with newly created profile.
2. Open https://mail.google.com/
3. Attempt to login

Actual Results:
Login fails:
The google say that
"Oops! Your browser seems to have cookies disabled. Make sure cookies are enabled or try opening a new browser window. "

I can log in with Aurora33.0a2 with the same profile.
This problem does not happen on Windows7.

Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/fdea170bd819
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825131454
Bad:
https://hg.mozilla.org/mozilla-central/rev/18901d4f3edd
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825132554
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fdea170bd819&tochange=18901d4f3edd

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7a3ee3395e46
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825054749
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7aa5eb424774
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825055648
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7a3ee3395e46&tochange=7aa5eb424774

Suspect: Bug 1054680
Summary: Cannot login to Gmail → Cannot login to Gmail on Ubuntu12.04 32bit
I gave the SQLite diff a pretty good skim but nothing seemed to jump out at me as likely to cause problems.  The most likely theory I would have is that SQLite has gotten better/more strict at detecting certain error cases.

I see that http://dxr.mozilla.org/mozilla-central/source/netwerk/cookie/nsCookieService.cpp is clever enough to re-create the database if it has trouble opening it the first time.  A problem that can occur is that SQLite encounters some failures at runtime after the database is opened.

But nsCookieService seems to have this taken care of.  nsCookieService::EnsureReadComplete does seem to handle this and has cases where it will invoke its HandleCorruptDB mechanism.  The async listeners seem to all inherit from DBListenerErrorHandler that should likewise trigger a rebuild of the cookie database.

So I'm not entirely sure what's up.  Needinfo'ing the cookies/permissions module owner, :mmc, to see if any ideas come to mind.

Alice0775 White, if it's possible to make a backup copy of your affected Ubuntu profile, I suspect that would be useful.  If you can run a debug build or build where http://dxr.mozilla.org/mozilla-central/source/netwerk/cookie/nsCookieService.cpp otherwise will have PR_LOGGING enabled, it seems like the cookie service might be quite willing to indicate what is going on with it.  Another possibility is to get a SQLite 3.8.6 binary and do something like "sqlite3 PROFILE/cookies.sqlite .dump".  If it gets to the end and prints "COMMIT;" without dying, it suggests it's not a case of corruption.

:ryanvm, I'm not exactly sure what we should do here, but I guess I'd be inclined for us to back out SQLite 3.8.6 since this seems like a pretty horrible regression no matter how many profiles it impacts.
Flags: needinfo?(ryanvm)
Flags: needinfo?(mmc)
Attached file profile
Maybe Richard has an idea?
Flags: needinfo?(ryanvm)
No ideas.

FWIW, I'm sending this message using the latest FF code out of Hg, modified with the latest trunk of SQLite, and using the "testprofile" in the attachment above.  I also tried creating a fresh profile.  Works in every case for me (on Ubuntu).  Dan has tried nightly with both a fresh profile and "testprofile" and also is unable to reproduce any problems.  I looked at all database files in the "testprofile" and didn't see any problems with any of them.
I am seeing the same error trying to open a GDocs document and I remember that it worked two days ago. Can't even log in using a Nightly from Aug 21st, which is before SQLite was upgraded. I assume that Google broke something on their servers.
Alice, here's a Try push of m-c tip with the SQLite update backed out. When the builds finish, can you please check to see if it helps?
https://tbpl.mozilla.org/?tree=Try&rev=b96451937dac
Flags: needinfo?(alice0775)
Last good nightly: 2014-08-05
First bad nightly: 2014-08-06

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7f81be7db528&tochange=6cbdd4d523a7
OS: Linux → All
Hardware: x86 → All
Summary: Cannot login to Gmail on Ubuntu12.04 32bit → Cannot log in to Google Accounts
Something is broken on google servers. I "downgraded" from nightly to aurora and I can connect again. Weird part is that I could connect two hours ago with my 3 days old homemade nightly build (because of crasher bug 1058567) and now I cannot anymore.
Yeah, seems to be a combination. Google changed something and we also introduced something a few weeks ago that breaks this.
According to regression range of Comment 8,

Setting network.http.spdy.enabled.http2draft = false and restart fixes the problem completely.
Flags: needinfo?(alice0775)
So, This is triggered by Bug 1047594.
Blocks: 1047594
No longer blocks: SQLite3.8.6
(In reply to Alice0775 White from comment #11)
> According to regression range of Comment 8,
> 
> Setting network.http.spdy.enabled.http2draft = false and restart fixes the
> problem completely.

"Dirty" workaround but it works. Thanks for it !
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #7)
> Alice, here's a Try push of m-c tip with the SQLite update backed out. When
> the builds finish, can you please check to see if it helps?
> https://tbpl.mozilla.org/?tree=Try&rev=b96451937dac

The try server does not fix the problem, so range of comment#1 is wrong. 
https://hg.mozilla.org/try/rev/b96451937dac
Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140827053723


I apologize for upsetting you; there was a wrong regression range on my part.
Component: General → Networking
Product: Firefox → Core
Component: Networking → Networking: HTTP
(In reply to Alice0775 White from comment #14)
> I apologize for upsetting you; there was a wrong regression range on my part.

Better safe than sorry! Thanks for all the bisection work you do, I know it's invaluable to lots of people.
Redirecting to Nick based on comment 11.
Flags: needinfo?(mmc) → needinfo?(hurley)
Well, isn't this fun to wake up to.

My best guess (for not having dug in at all) is that Google deployed h2-14 into production in the last 24 hours, and something got messed up in the process (I've been talking h2-14 to a staging endpoint at Google for the last two weeks with no issues). I'll get in touch with my Google contacts and start poking at Firefox HTTP logs to see if we can narrow down the cause of the issue.
Flags: needinfo?(hurley)
Hrm, I'm having trouble reproducing this on the most recent nightly. I have both h2 and ALPN enabled (the defaults in nightly), and we're negotiating spdy 3.1, not h2-14. I'm going to guess that I was correct in comment #17 (there's a problem on Google's end) and they pulled back h2-14 until they can fix it, but I'll double-check with my Google contacts to be sure.
OK, it appears that not all public frontends are speaking h2-14 yet, which would explain why some people can reproduce this and others (myself, for example) can't. I'm digging in deeper to see what is causing us to miss cookies (I have a suspicion, but want to be sure before I go proclaiming what the issue is).
Attached file http log
Another update - this definitely appears to be a google bug (from my end), as they are sending the set-cookie headers concatenated as one, joined by null bytes. This was totally legal in draft 13 (and indeed required to preserve header ordering), but has since been removed in draft 14 as we now have a simpler way to preserve header ordering. I've updated the google contacts with my evaluation, and will update this bug when I hear back from them with either a timeline for a fix or some evidence that throws my evaluation out the window :)
Got confirmation from google, a fix is being worked on.
Keywords: regression
Whiteboard: spdy
Summary: Cannot log in to Google Accounts → Cannot log in to Google Accounts (says cookies not enabled)
(In reply to Nicholas Hurley [:hurley] (Offline until 8 September 2014) from comment #22)
> Got confirmation from google, a fix is being worked on.

If we can get an ETA that might be good since this is having a clear impact on our nightly users.
Flags: needinfo?(hurley)
(In reply to Benjamin Kerensa [:bkerensa] from comment #30)

JFI: If you want that ETA in time you may have to ask someone else to reach out to the Google HTTP/2 contacts:

> Nicholas Hurley [:hurley] (Offline until 8 September 2014)
Comment 11 work-around seems to be working fine for me. An Exact ETA would be nice but not critical yet.
Comment 11 work-around seems to be working fine for me to.
Whiteboard: spdy → spdy, workaround: comment 11
Thank you Comment 11 did it for me. Thank you Alice0775 White
I now how to fix it .Please install normal Firefox .After you log in on YouTube and Gmail .And then remove Firefox .After you are happy because Nightly can allow you see your account. 

Thanks Team Mozilla for fix it.
This appears to be fixed now.
Flags: needinfo?(hurley)
This issue seems to still be present in the Nightly build for August 31, bkerensa I'm not sure what you did to fix it and pawel that's a completely useless solution. Using the workaround from comment 11 helps but I'd like to avoid an about:config change if needed. Hopefully Google patches things up on their end.
I'm still having the issue in today's Nightly and using Windows 7 64 bit.The workaround from comment 11 worked fine for me.
(In reply to Willy Cordeiro from comment #38)
> This issue seems to still be present in the Nightly build for August 31,
> bkerensa I'm not sure what you did to fix it and pawel that's a completely
> useless solution. Using the workaround from comment 11 helps but I'd like to
> avoid an about:config change if needed. Hopefully Google patches things up
> on their end.

What do you want? The change in about:config works fine and that's what's important.
But it's true that Google should fix the bug soon.
And why do you want to avoid a change in the configuration?
(In reply to Lucas Halbig from comment #41)
> And why do you want to avoid a change in the configuration?

It is for example highly inconvenient on Firefox OS devices where "about:config" is not available.
This is still present on the build I updated with 9/1/14. The fix from comment #11 offers a valid workaround.
We all are aware that this is an ongoing problem. So there is really no need to comment further on this bug, that comment 11 fixes it for you. We will inform you once this problem has been fixed. Thanks!
(In reply to Daniel Stenberg [:bagder] from comment #43)
> (In reply to Lucas Halbig from comment #41)
> > And why do you want to avoid a change in the configuration?
> 
> It is for example highly inconvenient on Firefox OS devices where
> "about:config" is not available.

To apply workaround to Firefox OS you must edit prefs.js accordingly. Example for my Flame device (must be accessible trough adb):

adb shell stop b2g
adb shell 'ls -d //data//b2g/mozilla/*.default/prefs.js'
//data//b2g/mozilla/2yauwo25.default/prefs.js
adb pull //data//b2g/mozilla/2yauwo25.default/prefs.js
echo 'user_pref("network.http.spdy.enabled.http2draft", false);' >> prefs.js
adb push prefs.js //data//b2g/mozilla/2yauwo25.default/
adb shell start b2g
I hope I'm allowed to add that the remark in Comment 1 just isn't correct.  I have this issue on Windows 7 32 bit, and have seen the error on Windows 7 64 bit.

Currently on Nightly 34.0a1 (2014-09-01)
(In reply to mixxster from comment #49)
> I have this issue on Windows 7 32 bit, and have seen the error on Windows 7 64 bit.

The bug's platform settings is correctly All/All, so it's known to be all systems
Summary: Cannot log in to Google Accounts (says cookies not enabled) → Cannot login to Google Accounts (says cookies not enabled)
[Blocking Requested - why for this release]:

QA blocking regression, since this causes a permafail in existing automation.
blocking-b2g: --- → 2.1?
Keywords: smoketest
Keywords: smoketest
(In reply to Jason Smith [:jsmith] from comment #52)
> [Blocking Requested - why for this release]:
> 
> QA blocking regression, since this causes a permafail in existing automation.

This is a google.com server bug and they just informed me (unverified) a fix has been pushed that should start showing up on thursday this week.
My symptoms are slightly different from comment 0. I do not see a problem with a freshly created profile, nor with a "Reset Nightly" profile. I do see it with my normal profile. (It's possible that I'm just hitting different servers or something, so this may not be relevant.) Turning off network.http.spdy.enabled.http2draft also works.

(I am only commenting in case people find this bug and conclude that it's different because it doesn't happen with a fresh profile.)
In my case it's always happening on Nightly. It doesn't matter if I'm using a fresh or my normal profile.

On Firefox 32 it work's just fine.
(In reply to Sergio Oliveira Campos from comment #58)
> In my case it's always happening on Nightly. It doesn't matter if I'm using
> a fresh or my normal profile.
> 
> On Firefox 32 it work's just fine.

Have you tried workaround in Comment 11?
The workaround works.
Baffled this is not fixed yet. Had to google "firefox gmail cookies disabled" and sort by last week to find this bug.
(In reply to Aaron Train [:aaronmt] from comment #61)
> Baffled this is not fixed yet. Had to google "firefox gmail cookies
> disabled" and sort by last week to find this bug.

I'd suggest looking at comment #53
Waiting on google for the fix.
Weird.  I'm seeing a similar problem on Google+ - and I already have http2draft set to false.  Also, although Tim Taubert says the problem happened between the 08/05 and 08/06 builds, mine broke between 07/31 and 08/03 (I don't see 08/01 or 08/02 builds on the FTP server).

Are we possibly being overzealous in closing all "Can't login to google" as dups?
I don't think so.
If you still have an old profile with Nightly and had cookies enabled, gmail will still "remember" you. Thus I have a working gmail-account on one machine and the problem with another one. And I only got the Problem because it became necessary for me to logout with a current account and Login with antoher one.
This didn't work and I even couldn't Login with the old one. So in my opinion this is weird.
And I didn' try the workaround because comment 53 says, it should be fixed by Google by tomorrow.
Just in case it helps, I had a pinned tab with gmail on it. It hasn't bee working for a number of days, no matter what I did (didn't see this bug up until now). Today, with the latest nightly, I tried again. Same result.

It then hit me that this happened before (or so I seem to recall). And what I did that time, and did now, was to close the pinned tab, open a new tab and go to gmail on that new tab. Worked perfect. Then I pinned it back. And the issue is not coming up again.
I am having sign in problem with youtube today network.http.spdy.enabled.http2draft true won't let me sign in
google tells me that rather than continuing to wait for the patch, they have disabled h2-14 at the alpn layer effective more or less at 5pm (pac) today (wed). That means we should negotiate spdy/3.1 with them and everything should work ok.

I'm not sure if that change is instantaneous or not - its certainly possible that it might need time to propagate fully.

If you don't restart you might need a ctrl-shift-reload to make sure any existing connections are re-negotiated. restarting nightly is probably not a bad idea either :)

I have confirmed that https://accounts.google.com/ wfm and negotiates spdy/3.1 at this time - but of course that's a giant CDN so ymmv for a bit.

I expect google will still roll out the above mentioned fix to their h2-14 stack and once that is done they will re-enable h2-14. I have tested account login with a staging server that already has that fix and confirmed it wfm so there is no particular reason to expect problems and I welcome more h2 interop testing.
Latest build (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140903030206 CSet: e58842c764dd) and in Rome (9:00 CET) I was able to login once again to Google. Maybe the Google patch arrived...
WFM as well!
I just tried this on the latest v2.2 Flame build and the issue is not reproducible.
I was able to login to gmail successfully.

Gaia      008026e932b64b4a70b9931c3da96986583bc8d4
Gecko     https://hg.mozilla.org/mozilla-central/rev/776fa9cf70cd
BuildID   20140904040204
Version   35.0a1
ro.build.date   Mon Jun 16 16:51:29 CST 2014
ro.bootloader   L1TC00011220
ro.build.version.incremental   109
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Pretty sure this should be Tech Evang, since this was an issue with a web server, not an issue with mozilla code. (And nothing landed to "fix" this in Mozilla code AFAICT, so FIXED is misleading with this being classified as a gecko bug.)

Apologies if I'm missing something (in which case, feel free to revert my change).
Component: Networking: HTTP → Desktop
Product: Core → Tech Evangelism
Version: 34 Branch → Trunk
blocking-b2g: 2.1? → ---
See Also: → 1067270
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.