Tested this issue on reported chromium/chrome version 66.0.3359.181 using ubuntu 17.10 and we are able to reproduce this issue only on chromium.

There is an existing issue about unable to log into chromium browser Issue 849077 but this specific issue is resulting in freeze. CC'ing "melandory@chromium.org" and adding Services>SignIn component for inputs from the respective team 

Thanks...!

Identical behavior in my case:

$ chromium
[1064:1064:0608/083210.185490:ERROR:gaia_auth_fetcher.cc(72)] Missing ID token on refresh token fetch response.

Version 67.0.3396.62 (Official Build) Arch Linux (64-bit)

System:    Host: KISE-004 Kernel: 4.14.48-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.0 Desktop: Xfce 4.12.4 
           tk: Gtk 2.24.31 Distro: Manjaro Linux 17.1.10 Hakoila 
Machine:   Type: Desktop System: Dell product: OptiPlex 990 v: 01 serial: <root required> 
           Mobo: Dell model: 06D7TR v: A02 serial: <root required> BIOS: Dell v: A16 date: 08/21/2012 

Similar behavior on google-chrome-stable (AUR archlinux)

After Sign in chrome hangs at 
https://accounts.google.com/signin/chrome/sync?ssp=1&continue=https%3A%2F%2Fwww.google.com%2F

Version 67.0.3396.79 (Official Build) (64-bit)

Mihai, could this have anything to do with your recent CLs with Dice and client IDs?

I cannot reproduce the issue on Debian and I do not have access to a Ubuntu.

+maroun@ as she worked on the ID token parsing.

The error "Missing ID token on refresh token fetch response." indicates that Chrome does not receive the ID token that is used to extract the child status - see in https://cs.chromium.org/chromium/src/google_apis/gaia/gaia_auth_fetcher.cc?rcl=081912ddbb22f436d93079ec491a0092e094e4cd&l=72
I have tested and I do not see any freeze when I simulate an empty ID token in a ToT Chromium build, so I cannot explain the freeze when this token is missing.
maroun@: It would probably be a good idea to see with the server-side engineers why the ID token is missing in these responses.


A potential explanation for the for the freeze is that at the end of the sign-in flow, Chrome displays a window-modal sync confirmation dialog (like the one attached). This takes the focus of the window and the user must interact with it. Maybe these is an issue with Chrome displaying this window-modal dialog on these platforms.

richardabbott@gmail.com: As I cannot reproduce the issue, would you be able to do the following test (this would allow us to isolate the issue):
* Create 2 windows in Chrome.
* On the first Chrome window, attempt to do a sign-in until it freezes.
* See if you can interact with the second Chrome window.

Tested this issue on reported chromium version 66.0.3359.181 using ubuntu 17.10 and below is the observation.

Note:
1. We are able to reproduce, 'unable to sign into chromium' issue 
2. We are not able to reproduce chromium freeze issue.Attaching Screecast for reference.

Thanks! 

Deleted: 850622.webm 5.4 MB

	850622.webm 5.4 MB View Download

phanindra.mandapaka@chromium.org: Does this work for Chrome on the same machine? is this related to the fact that you are signing in from Chromium?

I believe the issue is not related to the ID token fetch failure because we simply log the error, infer the account does not belong to a child and do not block the sign-in. See:
https://cs.chromium.org/chromium/src/google_apis/gaia/gaia_auth_fetcher.cc?q=%22Missing+ID+token+on+refresh+token+fetch+response%22&sq=package:chromium&g=0&l=72
https://cs.chromium.org/chromium/src/google_apis/gaia/oauth2_id_token_decoder.cc?gsn=IsChildAccountFromIdToken&l=86

Also, a failure would indeed happen in Chromium, given that only Chrome is whitelisted to receive the ID token.

Finally, we no longer need the ID token to detect child accounts, since we're now obtaining this information from the GaiaFE bridge.

+alemate@, should this part of the code still be accessible after the migration you've performed? Are you planning to clean it up? Is there a bug for it? Thanks.

@msarda: Tested this issue on reported Chromium and Chrome version 66.0.3359.181 using ubuntu 17.10 and below is the observation.

1. We are able to reproduce, 'unable to sign into chromium' issue and we are not seeing the chromium freeze.(Chromium behavior)
2. Chrome is working fine on Version 66.0.3359.181 & latest stable 67.0.3396.79 using ubuntu 17.10. No freeze or sign in issue on Chrome.

Thanks.!

As an update: I downgraded fontconfig because Chrome wasn't working with it, but this cause some other problems. Somewhere in there, both Chrome and Chromium started working with the sign-in. I ran a dnf-update this morning, which upgraded fontconfig again so Chrome doesn't run for me anymore.

I assume unrelated to fontconfig, but Chromium cannot sign in now, and in fact was hanging on startup, I believe when it tried to sign in, which is before anything shows up on the screen, so it just looked like a silent failure to start. After deleting all the chromium config chromium starts but login hangs.

@msarda@chromium.org: If I start two Chromium windows and login on one window, both windows hang.

Here are the last few lines from the Chromium debug log, if it helps:

[30488:30488:0611/114033.298709:WARNING:CONSOLE(2411)] "Unrecognized message from GAIA: userInfo", source: chrome://chrome-signin/gaia_auth_host.js (2411)
[30488:30488:0611/114033.301268:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized richardabbott@gmail.com to richardabbott@gmail.com
[30488:30488:0611/114033.301293:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized @gmail.com to @gmail.com
[30488:30488:0611/114033.301328:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized @gmail.com to @gmail.com
[30488:30488:0611/114033.301337:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized richardabbott@gmail.com to richardabbott@gmail.com
[30488:30488:0611/114033.301998:VERBOSE1:gaia_auth_fetcher.cc(561)] Starting OAuth token pair fetch
[30488:31038:0611/114033.302085:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: https://www.googleapis.com/oauth2/v4/token
[30488:31038:0611/114033.302157:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: https://www.googleapis.com/oauth2/v4/token
[30488:31038:0611/114033.302184:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: https://www.googleapis.com/oauth2/v4/token
[31154:31154:0611/114033.347955:VERBOSE1:gles2_cmd_decoder.cc(3575)] GL_EXT_packed_depth_stencil supported.
[30488:30488:0611/114033.571694:ERROR:gaia_auth_fetcher.cc(71)] Missing ID token on refresh token fetch response.
[30488:30488:0611/114033.571793:VERBOSE1:oauth2_id_token_decoder.cc(28)] Invalid id_token: not in JWT format
[30488:30488:0611/114033.571815:VERBOSE1:oauth2_id_token_decoder.cc(59)] Failed to decode the id_token
[30488:30488:0611/114033.571819:VERBOSE1:oauth2_id_token_decoder.cc(86)] Assuming non-child account due to decoding failure
[30488:30488:0611/114033.572077:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized @gmail.com to @gmail.com
[30488:30488:0611/114033.572092:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized richardabbott@gmail.com to richardabbott@gmail.com

If it helps, when trying on Chromium, not possible to do anything on second window, and Chromium freezes.
When doing this on Chrome, the second window will not load a web site likewise the first window. Chrome can be closed normally.

Deleted: Screenshot_2018-06-11_13-42-57.png 163 KB

	Screenshot_2018-06-11_13-42-57.png 163 KB View Download

Deleted: Screenshot_2018-06-11_13-38-44.png 237 KB

	Screenshot_2018-06-11_13-38-44.png 237 KB View Download

This line:
[30488:30488:0611/114033.301328:VERBOSE1:gaia_auth_util.cc(48)] Canonicalized @gmail.com to @gmail.com

Seems a bit strange, maybe an empty email somehow. Could this be related maybe?

I only have debian and I cannot reproduce on Chromium (version details 66.0.3359.117 (Developer Build) built on Debian 9.4, running on Debian buster/sid (64-bit)).

As we cannot repro, we're going to need help to isolate this further.

Could you please do the following test:
* Start Chromium with an empty data directory: /usr/bin/chromium  --user-data-dir=/tmp/chromium_debug_abc (the executable may be named chromium-browser on Ubuntu)
* Sign in with another account (ideally a new account that has no synced data)
* Tell us if Chromium continues to freeze.

Started Chromium
signed in with newly created account
Chromium froze

Deleted: Screenshot_2018-06-12_07-03-00.png 365 KB

	Screenshot_2018-06-12_07-03-00.png 365 KB View Download

[2018-06-13 06:54] [ALPM] upgraded google-chrome (67.0.3396.79-1 -> 67.0.3396.87-1)

Same behavior

I have tries reproducing this again and I cannot. I do not think we can make progress on this as we do not have the right tools.

As this is a Ubuntu Chromium custom build (my understanding that the Ubuntu owners do change the libraries and other sutff in Chrome), it may be a good idea to contact the Ubuntu Chromium owners and ask them to debug it.

I appreciate the difficulty of debugging when you can't reproduce on your system. Just want to point out I originally reported this on Fedora. It isn't an Ubuntu-specific problem.

Indeed, I my problem is on Manjaro, and Archlinux derivative.

Unable to reproduce the issue on reported chrome version 66.0.3359.181 using ubuntu 17.10. As per comment #22 we don't have Manjaro to test this issue. Hence removing the Bisect label to it.

Thanks!

Launching chromium with the option --password-store=basic resolved the problem with chromium.
Likewise 'google-chrome-stable --password-store=basic'
Ref:wiki.archlinux.org/index.php/Chromium/Tips_and_tricks#Force_a_password_store

Nice find: --password-store=basic also worked on chromium and Fedora 29.

As per comment#20 adding TE-NeedsTriageHelp label for further investigation from dev team and to remove this bug out of TE triaging bucket. Please remove if this is not the case.

Thanks!

Assigning to vasilii, as this looks related to password manager, per comments #24 and #25.

--password-store also affects encryption, which is probably why it hides the problem here.

Questions for those who can reproduce the problem:
1. Do you have gnome-keyring or kwallet installed? Presumably you are using gnome-keyring (aka libsecret).
2. Do you see a prompt to unlock gnome-keyring when you run Chrome? How do you respond to it?
3. Are you able to inspect your keyrings using Seahorse (Seahorse is usually already installed)? You should be able to find an entry named "Chrome Safe Storage" in your default keyring.

1. I have gnome-keyring installed.
2. I do not get a prompt to unlock the keyring.
3. Yes I can inspect in Seahorse. Should I be looking for something?

As a side-note, I'm logged into Chromium now via the --password-store=basic, so IDK whether the affects the answers to these questions.

1. Do you have gnome-keyring or kwallet installed? Presumably you are using gnome-keyring (aka libsecret).
=
# pacman -Qii gnome-keyring
Name            : gnome-keyring
Version         : 1:3.28.2-1
Description     : Stores passwords and encryption keys
Architecture    : x86_64
URL             : https://wiki.gnome.org/Projects/GnomeKeyring
Licenses        : GPL  LGPL
Groups          : gnome
Provides        : None
Depends On      : gcr  libcap-ng  pam  openssh
Optional Deps   : None
Required By     : None
Optional For    : chromium  git  google-chrome  libgnome-keyring  libsecret  xfce4-session
Conflicts With  : None
Replaces        : None
Installed Size  : 4.19 MiB
Packager        : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Build Date      : Mon 07 May 2018 01:56:34 AM PDT
Install Date    : Wed 06 Jun 2018 11:02:01 AM PDT
Install Reason  : Explicitly installed
Install Script  : Yes
Validated By    : Signature

2. Do you see a prompt to unlock gnome-keyring when you run Chrome? How do you respond to it?
=
No

Also see: https://wiki.archlinux.org/index.php/chromium#Hang_on_startup_when_Google_Sync_enabled

3. Are you able to inspect your keyrings using Seahorse (Seahorse is usually already installed)? You should be able to find an entry named "Chrome Safe Storage" in your default keyring.
=
No entry for any 'Chrome*'

Deleted: Screenshot_2018-06-20_11-43-02.png 56.4 KB

	Screenshot_2018-06-20_11-43-02.png 56.4 KB View Download

Please don't run with --password-store=basic when helping the investigation. It will hide all of the symptoms in Chrome.

re #30. Yes, please verify that there is an entry "Chrome Safe Storage" in your default keyring and that you can view it.

re #31. In your screenshot, I see no keyrings at all (there should be a section "Passwords" above "Certificates", with a list of your keyrings). It looks like Seahorse can't complete a query to keyring either, which means that the hang occurs in gnome-keyring. 

Can you try fixing your keyring? I'm not sure what would help here. You can try uninstalling and reinstalling gnome-keying/libsecret, and deleting and recreating its keyring folder (typically ~/.local/share/keyrings, but not necessarily)

re #32 Added a keyring using system password and rebooted.

now Chromium appears to run without problems signing out and in to chrome sync 

but google-chrome-stable fails to sign in to sync and hangs when attempting.

re #32,33

removed google-chrome profile, uninstalled google-chrome, reboot, install google chrome, again hung at sign-in sync

removed google-chrome profile, uninstalled google-chrome, reboot, install google chrome, sing-in to gmail, sign-in to-sync, success.

re #34
After success yesterday, today both chromium and google-chrome will not load web pages,and when signing out, then in to sync, both hang.
Firefox no problems.
---
when I try to open seahorse to check on key-chain, fails to open and I verify it is installed...?

Seems using lightDM in autologin requires a blank password for gnome-keyring.
(https://wiki.archlinux.org/index.php/LightDM#Enabling_autologin)

Setting the keyring password to blank made no effect in unhanging google-chrome.

Reverting the '--password-store=basic' option to launch made google-chrome functional again.

Apparently these problems are related to LightDM, autologin and gnome-keyring.

I was able to reliably reproduce this bug on a fresh install of Ubuntu 16.04.5 and a gmail.com account.

The machine had an autologin enabled.

The way out was to reboot, enter a password into gnome-keyring (a popup appeared right after the reboot) and only then sign into Chrome.

Let me know, if you need more details. Potentially, I can also try to create a cloud instance with a reproducer.

Hi krasin,
yes I would like some details :) This sounds like bug 660005, a sneaky bug in gnome-keyring we encountered in the past and I thought we had worked around.

1. If you have autologin enabled, then you shouldn't be asked to unlock gnome-keyring at all (by Chrome or anything else). Did you disable it before rebooting?

2. Is the problem solved permanently, or only if you unlock your keyring manually before launching Chrome?

3. Do you get similar problems in Seahorse (hang or keyrings not showing)?

4. Do you have a keyring named "Login"? Do you have additional keyrings?

If you are able to reproduce, I would like to see the logs, in case they show where the hang occurs
--enable-logging --v=1
https://www.chromium.org/for-testers/enable-logging

Thanks!