Closed Bug 1049299 Opened 10 years ago Closed 10 years ago

[e10s] Cannot login on various websites because cookies aren't sent in e10s

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
e10s m3+ ---

People

(Reporter: tetsuharu, Assigned: mrbkap)

References

Details

(Keywords: dogfood, reproducible)

Attachments

(1 file, 2 obsolete files)

[environment] - OS X 10.9.4 - Nightly: https://hg.mozilla.org/mozilla-central/rev/7f81be7db528 [Step to reproduce] 1. Set `network.cookie.cookieBehavior` to `1`. (Disable all 3rd party cookies). 2. Open https://accounts.google.com/ServiceLogin?service=mail&continue=https://mail.google.com/mail/. 3. Try log in. [Result] We cannot login to Gmail in e10s. [Expected] We login to Gmail in e10s. On non-e10s window, we can login to it if we set network.cookie.cookieBehavior = 1.
Blocks: core-e10s
I can reproduce this problem. This might be related to Blake's e10s password manager work.
That seems unlikely. It seems more likely to be related to bug 572151. I thought there was another e10s third-party cookie bug, but I can't find it. If it actually exists and isn't a figment of my imagination, it would be another likely candidate.
Another excellent candidate. Given the assignee (ahem) of the bugs in question here, I'll take this to make sure I remember to test it as I fix the other bugs.
Assignee: nobody → mrbkap
Summary: [e10s] Cannot login to gmail if `network.cookie.cookieBehavior` is `1` in e10s → [e10s] Cannot login to gmail when blocking all third-party cookies in e10s ("Accept third-party cookies:: Never")
Blocking third-party cookies is just totally broken right now. In e10s, it (as far as I can tell) stops us from sending any cookies at all. Once bug 1038756 is checked in, it should get a lot easier to fix that without writing too much code, so I'll re-take a look once that lands (see also bug 1042377, comment 2).
Depends on: 1038756
I just ran into a similar issue with network.cookie.cookieBehavior=3 under e10s and Nightly. The Web Console informs me "Content Security Policy: Couldn't parse invalid source https://apis.google.com/_/scs/abc-static/" (as well as a nearly-identical error for a similar URL). Same settings without e10s works fine. Do you want a separate bug for this one?
Ignore me. I need to do more testing. Was able to reproduce the issue without e10s. Something related to tabs in the main window…
Netflix and Mozilla's own Persona login system also suffers from this.
I can see the same with Nightly but outside of e10s! Similar to what has been mentioned in comment 7. Are you all sure this is e10s only? Maybe best here would be to do a regression range check, and if both are the same we could kill the e10s part here. [Tracking Requested - why for this release]: Being not able to log into several websites is a blocker for a release.
OS: Mac OS X → All
Hardware: x86 → All
I'm nt even sure if 3rd party cookies are involved here. Even with a default profile and this setting enabled I'm not able to login. Here the pushlog for m-c: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f198e81ed98&tochange=18f408a5984e I'm bisecting inbound builds now.
More details for inbound here: Last good revision: 6cbdd4d523a7 First bad revision: dfece7923301 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6cbdd4d523a7&tochange=dfece7923301 Only one of Bill's landed patches could have caused this. I will dig deeper.
The above pushlog as retrieved via mozregression doesn't seem to be correct. Please disregard it. I will redo it by building Firefox myself.
Ok, so the general problem with being not able to login to gmail has been caused by bug 1047594. I will now check if e10s behaves differently. If yes, I will file a separate bug.
Tested an e10s build and it indeed looks different. With both http/2 prefs disabled I can still not log into Gmail. So I have to re-do the regression test now. By checking bug 1047594 I noticed that there is already bug 1059074 for the case I have seen. Given that those prefs are enabled by default in Nightly builds, we need a fix on that bug first? At least I will mark the dependency.
Depends on: 1059074
Ups, looks like I missed comment 5. So lets wait for bug 1038756 to be fixed.
Summary: [e10s] Cannot login to gmail when blocking all third-party cookies in e10s ("Accept third-party cookies:: Never") → [e10s] Cannot login on various websites because cookies aren't sent in e10s
Even the feedback to mozilla could not be sent with e10s activated. Application Basics ------------------ Name: Firefox Version: 35.0a1 User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Multiprocess Windows: 0/1 Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Extensions ---------- Name: Adblock Plus Version: 2.6.4 Enabled: true ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Name: Add-on Compatibility Reporter Version: 2.0.4 Enabled: true ID: compatibility@addons.mozilla.org Name: Diccionario de Español/México Version: 1.1.3 Enabled: true ID: es-MX@dictionaries.addons.mozilla.org Name: Disconnect Version: 3.14.0 Enabled: true ID: 2.0@disconnect.me Name: DownloadHelper Version: 4.9.23 Enabled: true ID: {b9db16a4-6edc-47ec-a1f4-b86292ed211d} Name: DownThemAll! Version: 2.0.17 Enabled: true ID: {DDC359D1-844A-42a7-9AA1-88A850A938A8} Name: gTranslate Version: 0.9 Enabled: true ID: {aff87fa2-a58e-4edd-b852-0a20203c1e17} Name: HTTPS-Everywhere Version: 5.0development.0 Enabled: true ID: https-everywhere@eff.org Name: MEGA Version: 2.0.186 Enabled: true ID: firefox@mega.co.nz Name: Mozilla Archive Format Version: 3.0.2 Enabled: true ID: {7f57cf46-4467-4c2d-adfa-0cba7c507e54} Name: Privacy Badger Firefox Version: 0.1.4 Enabled: true ID: jid1-MnnxcxisBPnSXQ@jetpack Name: Spanish (Venezuela) spell check dictionary Version: 1.1.17 Enabled: true ID: es-ve@dictionaries.addons.mozilla.org Name: Speed Dial Version: 0.9.6.16 Enabled: true ID: {64161300-e22b-11db-8314-0800200c9a66} Name: YouTube ALL HTML5 Version: 2.1.3 Enabled: true ID: jid1-qj0w91o64N7Eeg@jetpack Name: Classic Theme Restorer Version: 1.2.3 Enabled: false ID: ClassicThemeRestorer@ArisT2Noia4dev Name: Hide My Ass Proxy Extension Version: 1.2.7 Enabled: false ID: extension@hidemyass.com Name: Nightly Tester Tools Version: 3.7 Enabled: false ID: {8620c15f-30dc-4dba-a131-7c5d20cf4a29} Name: Oxygen KDE Options Version: 3.7 Enabled: false ID: {c2a3f51e-2920-4eab-9008-1bcb44d21d57} Name: Personal Menu Version: 6.2.0 Enabled: false ID: CompactMenuCE@Merci.chao Name: QuickJava Version: 2.0.4 Enabled: false ID: {E6C1199F-E687-42da-8C24-E7770CC3AE66} Graphics -------- Adapter Description: nouveau -- Gallium 0.4 on NVA8 Device ID: Gallium 0.4 on NVA8 Driver Version: 3.0 Mesa 10.2.6 GPU Accelerated Windows: 0/1 Basic Vendor ID: nouveau WebGL Renderer: nouveau -- Gallium 0.4 on NVA8 windowLayerManagerRemote: false AzureCanvasBackend: cairo AzureContentBackend: cairo AzureFallbackCanvasBackend: none AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ accessibility.typeaheadfind: true accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 348160 browser.cache.disk.smart_size_cached_value: 358400 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 2 browser.places.importBookmarksHTML: false browser.places.smartBookmarksVersion: 7 browser.sessionstore.upgradeBackup.latestBuildID: 20140912030202 browser.startup.homepage: https://encrypted.google.com/ browser.startup.homepage_override.buildID: 20140912030202 browser.startup.homepage_override.mstone: 35.0a1 dom.mozApps.used: true extensions.lastAppVersion: 35.0a1 media.gmp-gmpopenh264.lastUpdate: 1405959171 media.gmp-gmpopenh264.path: /home/caralu74/.mozilla/firefox/1gj32y6s.default/gmp-gmpopenh264 media.gmp-gmpopenh264.version: 1.0 media.gmp-manager.lastCheck: 1410555690 network.cookie.cookieBehavior: 1 network.cookie.prefsMigrated: true places.database.lastMaintenance: 1410556595 places.history.expiration.transient_current_max_pages: 40801 plugin.disable_full_page_plugin_for_types: application/pdf plugin.importedState: true privacy.cpd.extensions-dta: true privacy.cpd.offlineApps: true privacy.cpd.siteSettings: true privacy.donottrackheader.enabled: true privacy.sanitize.migrateFx3Prefs: true storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1409586159 Important Locked Preferences ---------------------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.10.7 Version in use: 4.10.7 NSS Expected minimum version: 3.17.1 Basic ECC Beta Version in use: 3.17.1 Basic ECC Beta NSSSMIME Expected minimum version: 3.17.1 Basic ECC Beta Version in use: 3.17.1 Basic ECC Beta NSSSSL Expected minimum version: 3.17.1 Basic ECC Beta Version in use: 3.17.1 Basic ECC Beta NSSUTIL Expected minimum version: 3.17.1 Beta Version in use: 3.17.1 Beta Experimental Features ---------------------
Same problem with activate 3rd party cookies. [Step to reproduce] 1. Open https://accounts.google.com/ServiceLoginAuth 2. Login [Result] Google say I have disabled cookies and recommend my this help page https://support.google.com/accounts/answer/61416?hl=en [Expected] I should can be login.
Blocks: 1065042
Requesting re-triage on this, it's preventing me from logging into gmail, which blocks m3 bug 1065042.
I'm back from vacation and bug 1038756 is checked in. This is first on my list of bugs to fix.
Status: NEW → ASSIGNED
Adding "dogfood" keyword so this bug shows up on the e10s wiki's list of known issues: https://wiki.mozilla.org/Electrolysis#Known_Issues
Keywords: dogfood
Blocks: 805616
I'll attach a patch to this bug tomorrow morning.
Attached patch patch v1 (obsolete) (deleted) — Splinter Review
I realized that nsIHttpChannelInternal was sufficient for my needs. As far as I can tell, what's failing for the "3rd party cookies disabled" case was checking the parent chain of the channel's owner for 3rd-party-ness. We can compute that in the child and propagate it to the parent. Somewhat confusingly, "IsThirdPartyChannel" also takes a URI, so the fact that the channel itself is not 3rd party to its parents doesn't mean we can short-circuit the entire calculation.
Attachment #8505077 - Flags: review?(jduell.mcbugs)
Comment on attachment 8505077 [details] [diff] [review] patch v1 Review of attachment 8505077 [details] [diff] [review]: ----------------------------------------------------------------- The logic of ThirdPartyUtil::IsThirdPartyChannel is getting a little funky, but I'll gladly repay the technical debt next Tuesday for a tasty BugFix today. ::: content/base/src/ThirdPartyUtil.cpp @@ +1,1 @@ > +/* vim: set ts=2 sts=2 sw=2 et tw=80: */ Canonical modelines from the Style Guide is /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* vim: set sw=2 ts=8 et tw=80 : */ yeah I don't know why anyone uses emacs either :) @@ +166,5 @@ > NS_ASSERTION(aResult, "null outparam pointer"); > > nsresult rv; > bool doForce = false; > + bool checkParent = true; s/checkParent/checkWindowChain/ # to keep confusion between parent window and e10s parent/child to a minimum here. @@ +190,5 @@ > + if (flags & nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_THIRD_PARTY) { > + // Check that the two PARENT_IS_{THIRD,SAME}_PARTY are mutually exclusive. > + MOZ_ASSERT(!(flags & nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_SAME_PARTY)); > + > + // If we're not forcing and we know that the parent chain of the channel s/parent chain/window chain/ @@ +200,5 @@ > + > + checkParent = false; > + parentIsThird = true; > + } else { > + // In e10s, we can't check the parent chain in the parent, so we do so s/parent chain/window chain/ @@ +203,5 @@ > + } else { > + // In e10s, we can't check the parent chain in the parent, so we do so > + // in the child and send the result to the parent. > + // Note that we only check the parent if neither THIRD_PARTY_PARENT_IS_* > + // flag is set. // Note that we only check the window chain if we haven't already done so in the child, i.e neither THIRD_PARTY_PARENT_IS_* flag is set
Attachment #8505077 - Flags: review?(jduell.mcbugs) → review+
Attached patch Fix for test failures (obsolete) (deleted) — Splinter Review
The try push above was orange in several places because of tests and other code that uses the original interface. Due to laziness and general fear of breaking add-ons, I'm tempted to keep the interface (as with this patch, based on top of attachment 8505077 [details] [diff] [review]). Jason, what do you think?
Attachment #8508369 - Flags: review?(jduell.mcbugs)
Comment on attachment 8505077 [details] [diff] [review] patch v1 Review of attachment 8505077 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/protocol/http/HttpChannelChild.cpp @@ +1299,5 @@ > > + nsCOMPtr<mozIThirdPartyUtil> util(do_GetService(THIRDPARTYUTIL_CONTRACTID)); > + if (util) { > + bool thirdParty; > + rv = util->IsThirdPartyChannel(this, nullptr, &thirdParty); This required "nsresult rv" to compile locally for me.
Hey Blake, sorry for the late driveby here, but is there a way to easily modify this to accommodate https://bugzilla.mozilla.org/show_bug.cgi?id=1088183 as well? At first glance, it looks like not.
Attachment #8508369 - Flags: review?(jduell.mcbugs) → review+
Attached patch For checkin (deleted) — Splinter Review
Attachment #8505077 - Attachment is obsolete: true
Attachment #8508369 - Attachment is obsolete: true
Attachment #8512996 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: