pwnall@, can you please look into it of possible? This seems to be related to: https://bugs.chromium.org/p/chromium/issues/detail?id=795827

ddorwin@, is this a consistent repro?

Thank you!

So far, this has only happened once per user-data-dir, at a time I believe coincide with the M66 update (this followed an OS boot in all cases). I haven't tried to go back to M65 and try again. As I noted, it didn't appear to always happen, even on the same OS account.

There is one known cause for this happening on M66 (that got pointed out in a bug report... one day before M66 stable cut) --- basically some latent junk in the cookie database that M65 ignored can cause M66's migration of it to new schema to bail.  Note that going back to M65 with M66 dir will not really work well because of that same schema change.

If you do have old copies of profiles saved (backups?) it should be possible to check whether that root cause applies with a bit of sqlite3'ing

I've ran into this today. When I restart Chrome, I am signed out from logged in webpages, but the behavior is unpredictable - for example a few last restarts logged me out of Facebook, but now for some reason it keeps the session. I ran google-chrome wrapper script out of opt/google directory and errors like this appear - looks very relevant

[4697:4722:0424/193838.869792:ERROR:connection.cc(1888)] Cookie sqlite error 2067, errno 0: UNIQUE constraint failed: cookies.host_key, cookies.name, cookies.path, sql: INSERT INTO cookies (creation_utc, host_key, name, value, encrypted_value, path, expires_utc, is_secure, is_httponly, firstpartyonly, last_access_utc, has_expires, is_persistent, priority) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Will nuking the profile and recreating new one fix this? Clearing cookies from ctrl-shift-delete window didn't help.

re: comment #4: that's a separate bug --- the original report was about what happens with 66 upgrade.  

With your problem... nuking the profile would solve the immediate cause, but I don't know why you got into the state, so I can't be sure it will really stick (M67/dev does have some stats, but M66 doesn't).  Since you sound like you're on Linux --- any warnings around crypto, key storage and the like? One reason this can happen is if there is trouble accessing you desktop's key storage (secret service, kwallet, etc), in order to decrypt the cookies, which makes us get a little out-of-sync with ourselves.

Thanks for quick response, sorry for not providing all information from the start.

Actually you are totally right - I am using KDE 5 on Debian and since last computer restart I was getting this strange window about KWallet asking for password that I've never set (I never used it, was confused by that). Googling didn't help, so out of ideas I just force-removed kwallet package - turns out this was a mistake :( so then I tried to add "--password-store=basic" to wrapper script (yes I don't know what I am doing essentially) and the wallet window disappeared but this issue happened. So yeah, that's my fault :)

Thanks for pointing in the right direction. If I can help more then please ping me here, I'll try recreating the profile tomorrow.

Happened to me today after upgrading to ..

Version 66.0.3359.117 (Official Build) (64-bit)

.. for Linux.

On restarting the browser I was signed out of all google accounts (including 3rd party sites using my google credentials e.g., Citymapper) and all of the "other accounts" that I had previously configured had disappeared. Was also signed out of amazon.co.uk. Was still signed into bitbucket. After logging in again, restarting the browser hasn't shown the same behaviour .. so, hopefully a one off occurrence.

Just dealt with the exact same issue on OSX today going from 65 to 66.

Adding Mac, per #9.

I'm removing the release block label - I don't think there's any reason to believe this will happen again, with the 66-67 upgrade.

I have a customer experiencing this issue after upgrading to stable version 66, however, they are using a third-party SSO when signing-in. Any additional insights about this issue?

Started getting this today, after reinstalling a new OS from scratch recently. Now on Mint 18.x (current), KDE. With google-chrome-stable having this problem.

Was also getting kde wallet errors & changed kwalletrc to this to try to fix it:

[$Version]
update_info=kwallet-4.13.upd:kde4.13
Enabled=False
[Auto Deny]
kdewallet=google-chrome-stable

Plus I added --password-store=basic to my application menu entries. Still have problems when other apps open links in Chrome, just been closing that 'new wallet' dialog each time.

Don't know if these are related. I tried clearing all retained data from all time, & this one website remains problematic regarding staying logged in with a cookie: Voat.co, I even deleted its cookies & tried again after clearing data didn't help. Nothing seems to solve the issue. Annoying & would like a fix.

Re: comment #13 --- if that's what I think it is (bug #838901), the following might help, but it's a bit risky:

1) Exit chrome.
2) Backup ~/.config/google-chrome/Default/Cookies
(Might be in a different directory if you use multiple profiles).
3) sqlite3 ~/.config/google-chrome/Default/Cookies
4) DELETE FROM cookies WHERE host_key LIKE "%voat.co";

Hi team, issue still persist in version 66 (Stable) and Beta version 67 running in Windows 10.

@morlovich:

I got to step 3 then it failed.

>3) sqlite3 ~/.config/google-chrome/Default/Cookies

$ sqlite3 ~/.config/google-chrome/Default/Cookies
The program 'sqlite3' is currently not installed.

re: comment #16: it's probably in the "sqlite3" package.

re: comments #12, #15: so it feels like multiple issues are starting to get collated here --- some about one-time loss, one time about something that's continuous/can persist. 

I've installed sqlite3, then followed the instructions presented in comment #14. At step 4 I got an error message stating : "Error: no such table: cookies".

So I opened Chrome, closed the voat.co tab, then in settings deleted all the voat.co cookies there.

This time after logging back in to everything I stay logged in to, including voat.co- I was able to close & reopen Chrome without losing logged-in status on any sites that were set to remember.

I also have (/had?) this issue.

It seems to be fixed by deleting my browser profile and re-creating it.

Background:

Fresh install of Ubuntu 18.04 yesterday, fresh install of Chrome, logged into Chrome browser sync first, then logged into all of my "usual websites" (incl gmail, facebook, slack, todoist, discord).

When I restarted the browser, I was logged out of all sites and had to log in again (but did not have to 2FA again).

I deleted all of my cookies (via the settings menu). I was now able to stay logged in to Facebook, but not other sites.

I created a new browser profile, which seems to have fixed it: I signed into Gmail there and was still signed in after restarting Chrome.

I deleted my original browser profile and signed into the new profile with my google account, and now everything seems to be working fine without any issues (including no errors in the log).

-----

When running with logging turned on, about 30 seconds after I logged into Gmail (or other sites which would not stay logged in) I would get this line multiple times:

 [8344:8410:0505/173617.444425:ERROR:connection.cc(1888)] Cookie sqlite error 2067, errno 0: UNIQUE constraint failed: cookies.host_key, cookies.name, cookies.path, sql: INSERT INTO cookies (creation_utc, host_key, name, value, encrypted_value, path, expires_utc, is_secure, is_httponly, firstpartyonly, last_access_utc, has_expires, is_persistent, priority) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?)

I have two clients that have this issue. 

1. Using Windows 10, when he signs out of Chrome, all of his saved bookmarks, passwords and extensions are lost when signs in back again. Logged out of all websites he's logged into also. We then left his desktop during the weekend and now, he says his bookmarks are back, but still experiencing the same issue when logging in on other devices, Chromebook devices as he is an administrator at a school. 

2. Using Mac, she signs out, all of websites she is signed into, she gets logged out, username and password does not auto populate. Her bookmarks and extensions are reverted back to about two years before, as per her estimation, and any new ones added are lost when logs out and logs back in. 

Here are some of the troubleshooting I have done:
- Checked the settings on Admin Console, Ephemeral Mode is turned Off 
- Checked the Chrome Browser settings for sync, everything being synced 
- Checked the settings on myaccount.google.com and on "Apps with access", Chrome was listed 
- Checked saved passwords and there were multiple passwords that are saved, but still does not auto populate on password boxes when logging in to multiple websites 
- Reset the chrome settings to default, same behavior 
- Uninstalled and then installed chrome, same behavior 

Re: comment #22: that sounds like either sync or chrome sign in stuff and is unrelated. Please file a separate bug report for that. 

re: comment #20: it's quite interesting that it happened with a fresh install (assuming that includes fresh home directory?), in the "I have no idea on how things can possibly go wrong like that" sense.  Thank you quoting that error, too --- were there any other errors (as in not mentioning INSERT but some other command?)

The issue appears when there are rows in Cookie Database with the same host_key, name and path. 
Removing these rows solves this problem.
Chrome 66 clear all DB when it starts and Cookies contains these rows

Internal Vivaldi users have started reporting massive loss of logins after updating from our main v65 based version to the v67 based version.

I just reproduced this with a small profile (copied from the install used to write this message) . The profile had 85 cookies, after copying it into my v67 dev environment, and starting it, there were just 8 cookies left.

8? That's pretty weird, and may not be what I thought the problem was. What do the (host_key, name, path) tuples there look like?

(Also, please do anonymize the hosts as appropriate)

Actually, since it's 67 dev; could you take a peek at the Cookie.LoadProblem and Cookie.CommitProblem histograms in chrome://histograms (I think 67 finally has those...)

Among cookies gone are cookies for the domains ".facebook.com", ".chromium.org", "notifications.google.com", ".vivaldi.com", ".www.google.com",all of which had a single cookie.

I haven't done any detailed investigation of the Cookie file, or how the update is done, yet.

I could not find either of the histogram entries you mentioned in the histograms of the Release build I was using (not started heavy debugging, so far).

For reference, the usage scenario in my case is:
* Using a v65 based browser (Vivaldi 1.15)
* I am logged into Google and the codereview and bugs services.
* In my case I copied the User Data directory to the location of my dev build
* Started the build
* checked the list of cookies.

The second run I did, left 9 cookies.

Did it reopen any pages before you checked the cookie list?

To elaborate, there is a format migration in M66 that can drop the entire cookie jar in a "this surely never happens!" situation... which perhaps isn't as utterly exceptional as was thought when the code was written.  I expected the reports like this one to likely be caused by that, but that should result in zero cookies, not 9. And, well, it's kinda too late to fix that --- for Chrome --- but you may be able to do better, depending on what your schedule looks like.

Hmm, absence of Cookie.TimeDatabaseMigrationToV10 on first startup after going to M67 with M65 profile may also be some indication of that (though not 100% reliable).

(Context: https://cs.chromium.org/chromium/src/net/extras/sqlite/sqlite_persistent_cookie_store.cc?rcl=9a8e96b6fcd35d5cd9ed3908458be1ed3481bb23&l=1180)

I was resuming a session with 17 tabs (bugs and code-review; codereview went to signin for one of the tabs), and I know one internal user with the issue do that, too.

That could indicate that the cookie DB gets dropped and that the cookies I have are new ones set afterwards.

I assume that drop action is one of the return false in the case 9 section?

Do you have any suggestions or a patch for how to avoid the drop case?

Even if it is "too late", I think the problem should be patched in the chromium repo, too.

Didn't notice immediately, but I did get a "connection.cc(1888)] Cookie sqlite error 2067, errno 0: UNIQUE constraint failed: cookies.host_key, cookies.name, cookies.path" log entry for the table copy step

The DELETE FROM COOKIES one.

Hmm. There may be an easier way of doing this than I thought, by changing the 
the 'INSERT OR FAIL' to 'INSERT OR REPLACE', and then changing the SELECT to do ORDER BY creation_utc ASC  --- Victor, if you're reading this, does that sound sane to you? I suppose I should just ask with a CL).

(I thought it would take duplicating CookieMonster::TrimDuplicateCookiesForKey and a lot of bookkeeping, but doing this with SQL might actually be small)

I did a dump of the cookies, and I see that the duplicated cookies are mostly ".google.com" (or google national domain) cookies, although I did find  duplicated accounts.google.com, notifications.google.com cookies, too, and even a duplicated vivaldi.com cookie.

It could be that this duplication is just a result of multiple updates and refreshes, using INSERT, instead of UPDATE. (Just to be on the safe side, perhaps check if your current code do cookie updates correctly?)

I don't see any difference in the flags for the ones I have looked closely on; although there could be value differences (those did not get printed for some reason, local bug, probably).

The replace option sounds like a useful way to fix the problem, particularly if that results in a similar state as before.

The code at the higher level is supposed to delete old ones first, and seemed OK last time I stared at it. ... Though it only works before you get into the weird state place for the first time.

Tested the "INSERT OR REPLACE" option, that seems to work.

Two cookies did disappear, but AFAICT they expired.

Well, I just thought it would be useful to double check it. Given the new unique requirement, duplicates should be "impossible". What I am concerned about is if the delete step gets skipped for some reason; in that case the newer cookie will probably get lost.

Just uploaded https://chromium-review.googlesource.com/#/c/chromium/src/+/1097204

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

commit 6c41b439b9e299354f86b91426ff0f7196c13f90
Author: Maks Orlovich <morlovich@chromium.org>
Date: Wed Jun 13 22:19:44 2018

SQLitePersistentCookieStore: recover from uniqueness violation on V9->V10 migration

We can do better than just dropping the DB, by dropping just the older
versions of the duplicate cookie --- this is how M65 would behave when
loading the store, so it preserves old behavior.

This is probably too late for Chrome, but may help other embedders.

Bug:  835990 
Change-Id: I25bf87d46574346a47c05b35152fa3c42f9aa7a9
Reviewed-on: https://chromium-review.googlesource.com/1097204
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567018}
[modify] https://crrev.com/6c41b439b9e299354f86b91426ff0f7196c13f90/net/extras/sqlite/sqlite_persistent_cookie_store.cc
[modify] https://crrev.com/6c41b439b9e299354f86b91426ff0f7196c13f90/net/extras/sqlite/sqlite_persistent_cookie_store_unittest.cc

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.