Typo*
Expected Result:
---------------
1. User should be able to login successfully into gmail.com
2. User should be able to sign into chrome successfully from avatar icon without any error.

Though it is seen on latest M69 build ,not adding any blocker as issue is seen inconsistently.

This seems to be same as Issue 860038 and probably related to account-consistency flag.

Assigning to droger@ for inputs.

Just to update:

This issue is seen with default status of 'account-consistency' flag and works fine on enabling 'Enabled dice' under'account-consistency' flag in chrome://flags.

Yes, I think this is the same as Issue 860038.
We're investigating.

Just to update:

Seeing the same issue across all OS(Windows, Mac, Linux & CROS) & across all latest channels(Stable-67.0.3396.99,beta-68.0.3440.42,dev-69.0.3472.3 & Canary-69.0.3483.0).

Tried by launching chrome with all the combinations of 'Account consistency' flags in chrome://flags & issue observed very inconsistently.

Providing chrome://signin-internals info for reference.

Basic Information
Chrome Version	69.0.3483.0	 
Account Consistency	DICE preparing migration with Chrome sync Gaia endpoint	 
Signin Status	Not Signed In	 
TokenService Load Status	Load credentials finished with success	 
Last Signin Details
Gaia Authentication Result		 
RefreshToken Received		 
SigninManager Started		 
SigninManager Completed		 
Access Token Details By Account
Service	Requested Scopes	Request Time	Request Status
extension_downloader	https://www.googleapis.com/auth/chromewebstore.readonly
7/6/18, 3:42:06 PM	Failure: Not authorized.
Accounts in Cookie Jar
Email Address	Gaia ID	Validity
No Accounts Present.		
Accounts in Token Service
Accound Id	Has refresh token	Has persistent auth error
No token in Token Service.	null	null

droger@, Please take a look and provide fix asap.
Thanks..!

Looks like on stable 'Desktop Identity Consistency' was rolled in for some users recently and since this is seen across all milestones and OS hence updating blocker and milestone label accordingly. Marking this blocking for next releases of respective milestones.

We were unaware of this bug happening on 67 or 68. Thanks for the report.

We never could repro this issue though, can you give more details about how to reproduce it?

It would be very helpful to have more information.
Even basic information such as which combination of "Account Consistency" and Chrome version had the problem.

Screenshots of chrome-internals would also help.

Also note that "Account Consistency = Dice Migration" is partially launched on stable (and could be rolled back if needed).
Other values such as "Prepare Migration" and "Fix Auth Errors" have been launched for some time and probably can't be rolled back.

Before making any decision regarding releases and branches, we need to understand better what flags were used.

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

commit 3521e29690d3bee2aa883f91d2fb9abb9e0c054f
Author: Mihai Sardarescu <msarda@chromium.org>
Date: Fri Jul 06 13:28:19 2018

Set default value for ProfileIOData::ProfileParams::account_consistency

Bug:  860471 
Change-Id: Ie0ddf72a449e4504c81e2c5240a3c38e24873328
Reviewed-on: https://chromium-review.googlesource.com/1127621
Commit-Queue: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572948}
[modify] https://crrev.com/3521e29690d3bee2aa883f91d2fb9abb9e0c054f/chrome/browser/profiles/profile_io_data.cc
[modify] https://crrev.com/3521e29690d3bee2aa883f91d2fb9abb9e0c054f/chrome/browser/profiles/profile_io_data.h

(reposting same comment with a mistake fixed)

Our current hypothesis is that the dice milestone is wrong on the IO thread (but correct in the UI thread).
As a consequence is that the UI has Dice enabled, but the network requests don't.

The dice milestone is sent to the IO thread at startup. We can reproduce the symptoms by forcing the IO thread to have Dice disabled or Dice M1.

Some possible causes:

1) the dice mode is not sent correctly to the IO thread. Our investigations have been focussed on this, but so far we couldn't see a bug.

2) the dice mode changes after its initial state (not expected) and the IO thread is not updated of the changes (this is by design). I'm working on a CL to detect and prevents changes of the Dice mode after it is initially set.

3) the Dice mode is sent correctly to the IO thread, but the IO thread does not interpret it correctly (i.e. there is a bug in the code that sets the HTTP headers depending on the dice mode). We didn't investigate this one, because it seems unlikely (because the bug seems to persist until chrome restart, which points to a bug at initialization).

Ok I have something interesting:

in the video in the original report, at the second 00:13, we can briefly see a certificate error.

I believe the browser is simply misconfigured, but I'll investigate more.

The error is:

MANDATORY_PROXY_CONFIGURATION_FAILED

https://cs.chromium.org/chromium/src/net/base/net_error_list.h?rcl=0d2294665a71189cf92eaabca687eb26ba29aeac&l=235

Looking at the code, when such a proxy error happens, the request is immediately retried without the proxy. Not sure what can be the impact of that.

Issue 860038 has been merged into this issue.

+ melody/Craig - are we seeing any spikes of this issue in user feedback?

I did some quick checking and didn't see any clear spikes. No reports of this specific behavior on the forum, and nothing obvious in listnr yet either.

The error message mentioned in c15 is also mentioned in bug 860618, but not sure if there's any connection there.

We'll chime in again if we do start seeing a spike in feedback.

Thanks!

trying to centralize the information from Issue 860038:
dpapad managed to repro in debug and kindly investigated. He could see that the account consistency is actually right (Prepare Migration for him).
However the header is not added to the request, because the test [1] fails.


If we know that the account consistency is correct, then I can see maybe the CookieSettings rejecting the request [2], or somehow the URL not being recognized as a Gaia URL [3].

[1] https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_header_helper.cc?l=189-193
[2] https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_header_helper.cc?rcl=93cbfad1add58d084010138d90d7ab3f74e913d2&l=146
[3] https://cs.chromium.org/chromium/src/components/signin/core/browser/dice_header_helper.cc?rcl=2ea1f46791d6b47fffb9174e448306e6a9927b6d&l=197

Ok. After following the information in comment #20 I think I found the problem, which makes me think that this is WAI. Perhaps a better error could have been shown to the user.

I had cookies set to blocked at chrome://settings/content/cookies. Enabling cookies fixes the issue.

FWIW, with cookies disabled,  the early return at [1] is being hit. Both of the conditions within [2] return false.


[1] https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_header_helper.cc?l=147
[2] https://cs.chromium.org/chromium/src/components/signin/core/browser/cookie_settings_util.cc?g=0&l=18-19

jmukthavaram@chromium.org: It looks like you cannot sign in to gmail.com either. Could you please check that cookies are enabled for google.com and account.google.com (open chrome://settings/content/cookies).

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

commit bd4f0e2664884ef58b084576494c4cfa8112acdb
Author: David Roger <droger@chromium.org>
Date: Mon Jul 09 09:58:00 2018

[signin] Cache the computed account consistency value

The account consistency method should not change during the lifetime of
a profile.
This CL enforces it by computing it only once at startup.
A CHECK is kept in the code, to ensure that the computed value indeed
does not change, because that would be a bug worth catching.

ChromeOS has currently a bug where the value actually changes after
creation of the profile.

TBR=ellyjones

Bug:  860471 , 860671
Change-Id: I0f596c32c5e9489c7935f444df6c2cbc00ef1026
Reviewed-on: https://chromium-review.googlesource.com/1127670
Commit-Queue: David Roger <droger@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573257}
[modify] https://crrev.com/bd4f0e2664884ef58b084576494c4cfa8112acdb/chrome/browser/signin/account_consistency_mode_manager.cc
[modify] https://crrev.com/bd4f0e2664884ef58b084576494c4cfa8112acdb/chrome/browser/signin/account_consistency_mode_manager.h
[modify] https://crrev.com/bd4f0e2664884ef58b084576494c4cfa8112acdb/chrome/browser/signin/account_consistency_mode_manager_unittest.cc
[modify] https://crrev.com/bd4f0e2664884ef58b084576494c4cfa8112acdb/chrome/browser/ui/views/profiles/profile_chooser_view_browsertest.cc

Tested this issue on Windows 10,Mac 10.13.4 & debian rodate using chrome latest version-69.0.3486.0 as per C#0.Seems issue got fixed now.User able to login to gmail & sign into google account through avatar icon without any issue, hence adding TE Verified issues.

Note:
-----
No issue seen on any of the chrome versions(stable,beta,dev & Canary) now hence unable to provide the requested info as per C#21.
Please find the attached screencast fro reference.
Thanks..!

Deleted: 860471-windows.mp4 2.8 MB

	860471-windows.mp4 2.8 MB View Download

Thanks for the updates, if there is no pending work can we tag the bug as fixed?

Do we need to merge this to M68?

Closing as WontFix to unblock releases, it's not actionable now. Please re-open if it happens again.