Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 68.0.3440.84 using Mac 10.13.1. As the issue seems to be fixed in latest canary 70.0.3508.0 providing reverse bisect info.
Note: Issue is not seen on Ubuntu 17.10 and Windows 10.

Bisect Information:
-------------------
Good Build: 69.0.3444.0
Bad Build:  69.0.3443.0

Note: Taking the above versions in to consideration we performed tool bisect, but ended up getting all good builds, hence changed/moved the revision numbers accordingly to get the following change log.
https://chromium.googlesource.com/chromium/src/+log/59136cd0495372d4c0a3b90e31b3866c50f31759..a620981bebb0b189d90bd4f3302ee7c70e7317b5
Suspecting: https://chromium.googlesource.com/chromium/src/+/a620981bebb0b189d90bd4f3302ee7c70e7317b5
 
As we are not very sure about the suspect, CC'ing sangwoo.ko@ from above CL for further inputs and marking it as Untriaged. Hence requesting to assign it to the right owner.

Per comment #3, Good Build: 69.0.3444.0. Is this issue fixed in M69 Beta 69.0.3497.23? If yes, pls remove "Target-69" label.

Hello, vamshi@. I'm not sure what 'signing in to Chrome sync' means. Is it UI in chrome://settings? Also, my CL is for disabling accelerator in chrome://history so I think it's unlikely to affect sync related things. Thanks :)

Re: C#3 The issue got fixed in M69 Beta 69.0.3497.23, Hence removing "Target-69" label.

Re: C#4 After navigating to chrome://setttings -> click "sign in to chrome" -> Upon entering the credentials, clicking on sync in order to sync "Apps, Auto-fill, Bookmarks, Extensions, History, Passwords, Settings, Themes & Wallpapers, Open Tabs..."

Thanks!

Same issue on 69.0.3497.23 

vamshi.kommuri@: Please re-bisect and cross check this, looks like its still an issue on 69.0.3497.23 as per C#6. 

b3y0utub3@gmail.com Was the sign-in in step 1. successful?

Also adding sign-in component, maybe it'll ring the bell.

yeah I signed in closed the chrome signed in back and I saw that the information has expired I need to sign in again with a red icon 

Tried checking the Manual good/bad provided in comment#2, even after testing the scenario for 4-5 times by creating 2-3 new profiles, the chrome  version 69.0.3444.0 always showed good behaviour i.e., after chrome is launched - it was signed-in/synced under chrome://settings without having to login again. Attaching the screencast of such an instance for reference.
Note: Will soon re-run the per-revision bisect, to check for the correct change log.

Thanks!

Deleted: 869823.mp4 2.8 MB

	869823.mp4 2.8 MB View Download

I dontt have that version I have only 69.0.3497.23 
and the stable version from google.com/chrome

Adding M-69 labels per comment #6.

+ ewald@ - can you please confirm if this issue has already been addressed? Seems like this is fixed in M69, but need to confirm how widespread this is in M68 and if anything needs to be merged. 

1. Do you have "Keep local data only until you quit your browser" turned ON at chrome://settings/content/cookies?
2. Can you take a screenshot of chrome://signin-internals and post it to this bug?

I'm not sure what's going on here. I am not aware of any client-side fixes for a bug like this in M69. Adding Mihai and David to take a look tomorrow to see if they can figure out what's going on.

This is showing very inconsistent behaviour, Even after running the per-revision bisect couple of times we are getting irrelevant change log, though good/bad combinations are seen.

@msarda: Requesting you to help in further triaging of this issue.

Thanks!

To be able to debug this, please open chrome://signin-internals when this happens again and attach a screenshot here. I am afraid there is not much we can do without this information.

Thank you!

M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

vamshi.kommuri@chromium.org: You said that you could reproduce the issue. Would it be possible to take a screenshot of chrome://signin-internals when this happens and attach it to this bug?

I am afraid I have no information now that would allow me to debug this issue.

As per comment#19 providing the details of chrome://signin-internals of the version 69.0.3443.0 where the issue is reproducible. Along with that attaching the screenshot of the version 69.0.3444.0 for reference, which is working fine.

@msarda: Please find the attached screenshots and let us know if anything is needed, which would help you to debug this further.
Removing Needs-Feedback label.

Thanks!

Deleted: 869823-69.0.3443.0.png 396 KB

	869823-69.0.3443.0.png 396 KB View Download

Deleted: 869823-69.0.3444.0.png 538 KB

	869823-69.0.3444.0.png 538 KB View Download

Seems like a problem with loading the tokens from disk ("Load credentials failed with unknown errors")

I'm going to remove the "ReleaseBlock-Stable" label, since this doesn't seem like it's affecting a significant chunk of users, and we've seen issues with loading credentials from disk in the past. We know from UMA data that this happens fairly rarely.

Mihai and David - who are the right people to loop in about being unable to load credentials from disk?

After your comments I tried to fix this myself 
I went here /Users/{user}/Library/Application Support/Google/Chrome/Default 
and deleted "Login Data" and "Login Data-journal" this fixed the issue I dont see a login screen anymore after restarting the chrome

As per comment#23 i.e., we've seen issues with loading credentials from disk in the past, removing Needs-Bisect label. Please feel free to add it back if required.

Thanks!

Removing the sync component; if you disagree, please put it back! :)

Given that the issue was resolved for the user, I don't know whether we'll be able to do any more effective debugging. Should we just close this out?

This is a recurrent issue we have when we load tokens from disk if somehow we fail to decrypt the token. It may be due to 2 reasons:
* the keychain is locked for whatever reason when we try to load the tokens and thus loading fails. retrying may help in this case.
* the keychain is permanently locked or the token data on disk is corrupted. There is not much we can do in this case.

cfroussios@: From your experience working with OS encrypt/decrypt functions, would it be of any use to add retry logic for loading tokens?  

There is a third reason
* the keychain is in a bad state and fails to give us the key, even though it is unlocked. Restarting the machine is the only known solution.

Retrying at the level of the client of encryption (sync, cookie store etc) will have no effect, because we cache the result of our query to Keychain.

Retrying our query to Keychain is possible, but it is unlikely to have a positive effect.
1. If the user chose to reject our request to read the Keychain, they will probably do so again. And they won't appreciate being asked twice.
2. If the keychain is in a bad state, failures are very consistent in my experience.
3. If the data isn't decryptable by the key that we have in Keychain, then the data is lost.

Out of those, 2. has an alternative solution, which is to inform the user that we failed to access their Keychain and that their Keychain may need to be restarted. It may be possible for Chrome to restart the Keychain automatically, but such an initiative may also be too invasive for a browser.

OK, then I think we should explore a way to inform the user that we failed to decrypt the token data (maybe an infobar or something) and tell them to restart (the machine or the browser?).

SGTM. Restarting the browser doesn't change anything AFAIK. Restarting the machine fixes a Keychain that's failing for no good reason.

Also, I realised that some kind of notification would be useful also when the user chooses to keep their Keychain locked. It's not obvious what we use Keychain for and some users assume we don't need access unless we need to read saved passwords.

Sabine: This bug is very long, but the only thing that came out is that we should inform the user that we failed to decrypt the token data from disk. Maybe this is something as simple as an infobar. Or maybe we want to have a more user friedly UI.

I am assigning this bug to you and CCing Johannes for guidance on the UI.

The password manager suffers as well, so let's talk together.

 Issue 915502  has been merged into this issue.