https://bugs.chromium.org/p/chromium/issues/detail?id=913284 might or might not be related to this current issue.

#2: It looks too similar to my case to be unrelated. Mine might be easier to repro though. (I tried yours and it didn't trigger the issue.)

I also tried bisecting but the developer builds did not exhibit this behavior.

Other people are running into this problem as well:

https://www.reddit.com/r/chrome/comments/a4foyh/gmail_on_chrome_only_too_many_redirects_new/

https://www.reddit.com/r/chrome/comments/a3db4x/gmail_too_many_redirects_with_3rd_party_cookies/

Tried testing the issue on reported chrome version #71.0.3578.80 using Ubuntu 14.04 and Ubuntu 17.10 by following below steps.

Steps:
=====
1.Launched chrome through terminal.
2.Navigated to "chrome://settings/content/cookies" and enabled "Block third-party cookies".
3.Visited "mail.gogle.com" and signed into the account.
4.Clicked around a bit.
5.Closed the chrome and reopened it through the terminal with "--proxy-server=invalid".
6.Navigated to "mail.google.com".
7.Observed and error as "The site cannot be reached" and "ERR_FAILED".
8.Repeated the above steps multiple times but unable to find "ERR_TOO_MANY_REDIRECTS" error.

Attached screencast for reference and tentatively adding Internals>Network>Cookies component.
@reporter: Could you please review the attached screencast for reference and let us know if anything is being missed here.
Thanks.!

Deleted: 913220.webm 8.5 MB

	913220.webm 8.5 MB View Download

Those are the steps that worked for me. It might be harder to repro on different environments.

I was able to repro on both Ubuntu 14.04 and 18.04 (in VirtualBox) but it wasn't always quick.

Possibly more reliable steps (no clicking around and starting with a new profile each time):

1. Start Chrome with a new temporary profile: google-chrome --user-data-dir=gmail-test
2. Enable "Block third-party cookies" in chrome://settings/content/cookies
3. Visit https://mail.google.com/ — sign in and open DevTools in the Application -> Service Workers section — wait for sw.js to register and then wait a few more seconds
4. Close Chrome and rerun it with: google-chrome --user-data-dir=gmail-test --proxy-server=invalid
5. Try visiting https://mail.google.com/ again — notice if the "Loading Gmail" page appears briefly
6. Close Chrome and rerun it normally: google-chrome --user-data-dir=gmail-test
7. Try visiting https://mail.google.com/ — you should get an ERR_TOO_MANY_REDIRECTS error page
8. If it loads normally, remove the "gmail-test" directory and go to step 1

Attached screencast is from Ubuntu 18.04 running in VirtualBox. Chrome was downloaded from google.com/chrome and was version 71.0.3578.80.

Deleted: broken-gmail-ubuntu.mp4 3.2 MB

	broken-gmail-ubuntu.mp4 3.2 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Despite the excellent instructions, no luck reproducing with a source build of 71.0.3578.80 (or trunk, which you also mentioned)

Are you running any extensions?  If so, could you try (temporarily) disabling them, and see if the issue goes away?

@morlovich: Can you please try with an official build of 71.0.3578.80? For me it happens with both official Chrome and Arch Linux's Chromium (which uses is_official_build=true).

@mmenke: No extensions; I am using a new profile to repro. In #6 I created a new profile with each attempt (though in the screencast it worked on the first try).

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Having similar issue and disabling a VPN extension that was forcing "block 3rd party cookies" fixes the issue of logging out of my google account.

Still reproducible with: 71.0.3578.98 (Official Build) (64-bit)

#12: Aside from unblocking third-party cookies, another workaround is to navigate to "chrome://settings/cookies/detail?site=mail.google.com" and remove its "Service Workers" by clicking on the "X" on the right. After that, Gmail opens without issue. :\

It reproduced successfully from a binary on 71.0.3578.98 Windows for me, but I kinda need a source build to be able to debug this well...

Let's see if something built on this machine would work...  

 Issue 913284  has been merged into this issue.

After one happy day of bisecting between the M70 and M71 branch points, I ended up at this change:

  https://chromium-review.googlesource.com/1213082

  "Harden StaticCookiePolicy to treat empty GURLs as third-party."

At least it sounds relevant and is small! I'll try building master next to verify that the issue still exists there.

Tagging with M-71/RB-Stable for tracking purpose and if we plan any more stable refresh.

cc'ing some other reviewers from that CL

Hrm...That CL seems like a bad idea, as it affects all internal requests made by the browser process, doesn't it?

re: comment #20
I did notice things like omnibox being unable to set cookies with 3rd-party cookie blocking on when trying to reproduce this; I am not sure that people who use this sort of privacy-cautious setting would find that a bug, though.

re: comment #17: that's obviously amazingly helpful. Could you share what sort of args.gn you used (might need to censor the API keys, of course).

@morlovich: I use the same flags as Arch's Chromium package:

  https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium&id=2de9e2866942#n140

I can't think of anything other than is_official_build=true making a difference, considering this issue is reproducible with official Chrome but not the developer builds downloaded by bisect-builds.py. (Or perhaps it was the lack of API keys, though I remember trying to use Arch's API keys with the developer builds.)

FWIW I was unable to repro on master@{#616547}, so now I'm trying another bisect to see what commit (M71..master) might have fixed it.

Retired the issue on reported chrome version #71.0.3578.80 using Ubuntu 14.04 by following below steps.

Steps:
=====
1.Launched chrome through the terminal with --user-data-dir=gmail-test.
2.Enabled "Block third-party cookies" in chrome://settings/content/cookies.
3.Navigated to "mail.google.com", and signed into the Gmail account.
4.Opened DevTools->Application->Service Workers section, waited for sw.js to register and then waited few more seconds.
5.Closed chrome and reopened with --user-data-dir=gmail-test --proxy-server=invalid.
6.naviagted to "mail.google.com" and found an error "ERR_FAILED".
7.closed the chrome and re-ran it with --user-data-dir=gmail-test.
8.Observed that Gmail account opened successfully.
9.Closed chrome and opened it again in terminal normally(Executable Path).
10.Navigated to "mail.google.com", it asked for a sign in.
11.Tried again by launching it with --user-data observed that it asked for a sign in.

Attached screencast for reference.
@reporter: Could you please review attached screencast and let us know if anything is being missed here.
Thanks.!

Deleted: 913220_New.webm 20.7 MB

913220_New.webm 20.7 MB Download

#23: It might be harder to repro on your particular environment. Please avoid wasting more time on this if it's not readily reproducible. That said, the steps 1-8 you listed are correct. Since Gmail loaded successfully in step 8, I would have deleted the "gmail-test" directory and tried again with a new temporary profile.

Reproduced with source build using Arch-like args.gn. Thus far I am only seeing blocked cookie gets, for google.com cookies on mail.google.com URLs, with an empty site_for_cookies.

traffic annotation is 81157007 which is resource_dispatcher_host. I guess I need to add some debug output there for things that don't set site_for_cookies next...

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@morlovich: Could those cookie gets originate from the service worker which somehow has an empty site_for_cookies? It would explain why deleting the "Service Workers" for mail.google.com allows Gmail to load.

My M71..master bisect seems to be going well. Assuming no build issues, I should be able to find the commit that stops this issue from reproducing in a few hours. Would be really nice if it turns out to be an issue that has been fixed already. :)

[46712:46761:1214/132616.814526:ERROR:resource_dispatcher_host_impl.cc(1045)] Request with blank site_for_cookies:https://mail.google.com/mail/u/0/ is_prerendering:0 load flags:18432 resource type:6 originated_from_service_worker:0 fetch_request_context_type:0 is_main_frame:1

<snip a bunch of redirects>

[46712:46761:1214/132622.929270:ERROR:resource_dispatcher_host_impl.cc(1045)] Request with blank site_for_cookies:https://mail.google.com/mail/u/0/?<snip># is_prerendering:0 load flags:2049 resource type:6 originated_from_service_worker:0 fetch_request_context_type:0 is_main_frame:1

In M71 (different in trunk) 
18432 is LOAD_MAYBE_USER_GESTURE | LOAD_MAIN_FRAME_DEPRECATED
2049 is LOAD_MAIN_FRAME_DEPRECATED | LOAD_VALIDATE_CACHE

resource_type = 6 is however   RESOURCE_TYPE_SUB_RESOURCE = 6,     // an "other" subresource. 
... which confuses me.

Per offline group chat, we're not blocking M71 further roll out. We will pick up this change once ready and well baked in lower channels for future M71 respin (if any). Thank you.

+falken for service-worker expertise.

This seems to help, though it's probably not quite right, since if it is, why the TODO?

(confused why the method with this name matters, too)

--- a/content/browser/service_worker/service_worker_fetch_dispatcher.cc
+++ b/content/browser/service_worker/service_worker_fetch_dispatcher.cc
@@ -625,7 +625,7 @@ bool ServiceWorkerFetchDispatcher::MaybeStartNavigationPreload(
   network::ResourceRequest request;
   request.method = original_request->method();
   request.url = original_request->url();
-  // TODO(horo): Set site_for_cookies to support Same-site Cookies.
+  request.site_for_cookies = original_request->site_for_cookies();
   request.request_initiator =
       original_request->initiator().has_value()
           ? original_request->initiator()

Well, this is interesting...

As per my comment #17, this issue started with: https://chromium-review.googlesource.com/1213082

In comment #22 I mentioned that it didn't repro on master; that was because ServiceWorkerServicification was enabled by default in: https://chromium-review.googlesource.com/1286238

It's still reproducible on 73.0.3639.1 after disabling: chrome://flags/#enable-service-worker-servicification

And fieldtrial testing (https://crbug.com/846235#c32) explains why it didn't repro with Chromium builds (without setting fieldtrial_testing_like_official_build=true).

TL;DR: Should still be reproducible on master by following the steps in comment #6 after having disabled: chrome://flags/#enable-service-worker-servicification

@morlovich (#32): That does seem to fix it (tested on top of master@{#616939}). Aside from the TODO's existence, it's also unclear exactly what triggers this issue when running with an unreachable proxy.

I also managed to hit this when trying to load Gmail immediately after my laptop came out of standby and hadn't connect to WiFi yet. Several users seem to be having the same issue, so perhaps a priority bump would be in order. [1]

[1] https://productforums.google.com/forum/#!topicsearchin/gmail/ERR_TOO_MANY_REDIRECTS%7Csort:date

Thanks this looks quite bad. Setting Pri-0 based on the link in comment 35. 

I don't know why we left setting |site_for_cookies| as a TODO as comment 32 shows.

It's likely the bug doesn't occur when service-worker-servicification because there is no conversion from a URLRequest to a ResourceRequest in that case: we get the original ResourceRequest already (ServiceWorkerServicification uses ServiceWorkerFetchDispatcher::MaybeStartNavigationPreloadWithURLLoader instead of ServiceWorkerFetchDispatcher::MaybeStartNavigationPreload).

Fortunately, SWS is on at 50% on Stable 71 and I was planning to ramp it up to 100% anyway. I'll look into expediting that rollout and adding test coverage for this.

I have a demo at https://mattto.github.io/sw/test/navigation-preload-third-party-cookie/index.html. That page makes an iframe for a third-party site that has navigation preload enabled. I've verified that when SWS is on and third-party cookies blocking is on, the iframe can't send a nav preload or have a controller. When third-party cookies blocking is off, the |site_for_cookies| set at MaybeStartNavigationPreloadWithURLLoader has the correct value of the top-frame.

So a workaround for users should be to go to chrome://flags and turn #enable-service-worker-servicification to Enabled. I'll also see if I can rolling out the configuration to 100%.

@falken: Rolling out said configuration to 100% would only affect official Chrome, right? I suppose for my Arch Linux Chromium build I need to grab CL 1286238 which sets kServiceWorkerServicification to be enabled by default? :)

Yes, I think that may be right, unless you set --variations-server-url to get the Chrome Variations with a config that will enable ServiceWorkerServicfication.

I haven't confirmed if this is exactly what happened with Gmail, but the bug is likely that cookies aren't sent in the navigation preload request when third-party cookie blocking is enabled, even if the navigation is for the top-level frame. I'm guessing the lack of cookies is confusing Gmail sign in somehow. Not sure what that has to do with the proxy server. I notice the proxy server requests also go through a StaticCookiePolicy::CanAccessCookies check with an empty site_for_cookies.

 Issue 915106  has been merged into this issue.

The proxy server bit can probably be generalized as network unavailability while navigating to Gmail with a previously authenticated session (and installed service worker). The part I still find confusing is that Gmail remains broken afterwards. Enable SWS and Gmail will happily load; disable it and the too_many_redirects error returns. I can see how the error might originate from cookies not being sent, but it's weird how Gmail worked fine before the network unavailability event (with SWS disabled).

 Issue 915407  has been merged into this issue.

I have a CL under review at https://chromium-review.googlesource.com/c/chromium/src/+/1379792 which should fix this for the non-ServiceWorkerServicification path and more importantly (as that path is no longer the default on trunk) adds tests coverage.

I have an internal CL for rolling ServiceWorkerServicification out to 100% for official builds at cl/225760097.

I notice iOS is checked. Do we know if the issue affects iOS as well? These fixes wouldn't help as they are fixing a bug in //content with our service worker implementation.

Issue 912207 has been merged into this issue.

Thank you falken@. We're are going to ramp up M71 stable rollout to 100% today for Desktop and Android. Pls submit  cl/225760097 ASAP if 50% rollout data continue to look good. Thank you.

The CL changing ServiceWorkerServicification to 100% has been submitted.

Thank you falken@. Is it safe to remove "RBS" label now?

Yes the binary should work as-is without blocking stable, so long as the ServiceWorkerServicification rollout succeeds.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3

commit c0d0bacc0ae01f15c4d06405057fd35f371bcaf3
Author: Matt Falkenhagen <falken@chromium.org>
Date: Tue Dec 18 08:31:08 2018

service worker: Fix nav preload with third-party cookie blocking.

In non-ServiceWorkerServicification, the navigation preload request
wasn't setting site_for_cookies field when converting from a URLRequest
to ResourceRequest, so StaticCookiePolicy was blocking cookie access
when third-party cookie blocking was enabled.  This meant that cookies
weren't sent in the navigation preload request.

ServiceWorkerServicification already set set_for_cookies since it just
passed the ResourceRequest on to the URLLoader for navigation preload.

Test coverage is added as a //chrome browser test.

Bug:  913220 
Change-Id: I03acb2c0b67d4645d3f6147b2ac9426a68935dee
Reviewed-on: https://chromium-review.googlesource.com/c/1379792
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617414}
[modify] https://crrev.com/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3/chrome/browser/chrome_service_worker_browsertest.cc
[add] https://crrev.com/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3/chrome/test/data/service_worker/create_service_worker.html
[add] https://crrev.com/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3/chrome/test/data/service_worker/navigation_preload_worker.js
[add] https://crrev.com/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3/chrome/test/data/service_worker/page_with_third_party_iframe.html
[modify] https://crrev.com/c0d0bacc0ae01f15c4d06405057fd35f371bcaf3/content/browser/service_worker/service_worker_fetch_dispatcher.cc

Dropping priority as the server-side config change happened.

Remaining work is to merge #51 to 72 as a precaution in case ServiceWorkerServicification needs to be disabled in 72.

Created issue (https://bugs.chromium.org/p/chromium/issues/detail?id=912207&desc=2) and t/ 36513643 regarding this issue on iOS. User has completed comment #12 and #13 and issue is still affecting mail.google.com. However, user is able to access in a incognito window. 

 Issue 915428  has been merged into this issue.

I'd like to merge c#51 to M72. This fixes Gmail sign-in with third-party cookies blocked when ServiceWorkerServicification is disabled. Currently ServiceWorkerServicification is launched in 71 but there is a non-zero chance it must be reverted in 72, which would trigger this bug again.

The change has been through Canary but that doesn't mean much because ServiceWorkerServicification is enabled there. On the other hand, the fix is one-line and has test coverage so I'm reasonably confident it's OK (and most likely it won't have any effect as 72 probably will have ServiceWorkerServification enabled).

This bug requires manual review: M72 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M72 branch 3626 based on comment #55. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a7896a704229c3ffb38ffe4852aec109ecd3bc50

commit a7896a704229c3ffb38ffe4852aec109ecd3bc50
Author: Matt Falkenhagen <falken@chromium.org>
Date: Fri Dec 21 06:32:27 2018

M72: service worker: Fix nav preload with third-party cookie blocking.

In non-ServiceWorkerServicification, the navigation preload request
wasn't setting site_for_cookies field when converting from a URLRequest
to ResourceRequest, so StaticCookiePolicy was blocking cookie access
when third-party cookie blocking was enabled.  This meant that cookies
weren't sent in the navigation preload request.

ServiceWorkerServicification already set set_for_cookies since it just
passed the ResourceRequest on to the URLLoader for navigation preload.

Test coverage is added as a //chrome browser test.

Bug:  913220 
Change-Id: I03acb2c0b67d4645d3f6147b2ac9426a68935dee
Reviewed-on: https://chromium-review.googlesource.com/c/1379792
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#617414}(cherry picked from commit c0d0bacc0ae01f15c4d06405057fd35f371bcaf3)
Reviewed-on: https://chromium-review.googlesource.com/c/1388051
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#495}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/a7896a704229c3ffb38ffe4852aec109ecd3bc50/chrome/browser/chrome_service_worker_browsertest.cc
[add] https://crrev.com/a7896a704229c3ffb38ffe4852aec109ecd3bc50/chrome/test/data/service_worker/create_service_worker.html
[add] https://crrev.com/a7896a704229c3ffb38ffe4852aec109ecd3bc50/chrome/test/data/service_worker/navigation_preload_worker.js
[add] https://crrev.com/a7896a704229c3ffb38ffe4852aec109ecd3bc50/chrome/test/data/service_worker/page_with_third_party_iframe.html
[modify] https://crrev.com/a7896a704229c3ffb38ffe4852aec109ecd3bc50/content/browser/service_worker/service_worker_fetch_dispatcher.cc

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/a7896a704229c3ffb38ffe4852aec109ecd3bc50

Commit: a7896a704229c3ffb38ffe4852aec109ecd3bc50
Author: falken@chromium.org
Commiter: falken@chromium.org
Date: 2018-12-21 06:32:27 +0000 UTC

M72: service worker: Fix nav preload with third-party cookie blocking.

In non-ServiceWorkerServicification, the navigation preload request
wasn't setting site_for_cookies field when converting from a URLRequest
to ResourceRequest, so StaticCookiePolicy was blocking cookie access
when third-party cookie blocking was enabled.  This meant that cookies
weren't sent in the navigation preload request.

ServiceWorkerServicification already set set_for_cookies since it just
passed the ResourceRequest on to the URLLoader for navigation preload.

Test coverage is added as a //chrome browser test.

Bug:  913220 
Change-Id: I03acb2c0b67d4645d3f6147b2ac9426a68935dee
Reviewed-on: https://chromium-review.googlesource.com/c/1379792
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#617414}(cherry picked from commit c0d0bacc0ae01f15c4d06405057fd35f371bcaf3)
Reviewed-on: https://chromium-review.googlesource.com/c/1388051
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#495}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

It looks like we may need to disable servicification in 71 due to  issue 918944  and  issue 916514 . Requesting merge to 71 as well, see comment #55.

Also, iOS shouldn't be affected by this. It's a bug in Chrome's content/web platform layer which iOS doesn't use. Re comment 53: that user appears to be using Mac OS not iOS.

https://chromium-review.googlesource.com/1396002 works fine for me when applied to Chromium 71, though I've only taken the one-line change in the code and left out the tests.

Will ServiceWorkerServicification need to be disabled by default in M72 or are you working out the remaining issues so it can be left enabled? (Asking because I don't/can't use variations in my Arch Linux builds to turn it on or off.)

#63: I'm working on the issues so ServiceWorkerServification can remain enabled in 72.

Removing 71 target per https://bugs.chromium.org/p/chromium/issues/detail?id=918944#c29.

Well, I guess technically the bug is fixed in 71 due to the variations framework; the merge request is the only thing to remove.