Thanks for the report! I believe this is a duplicate of Issue 842673.

Actually, it might not be, since the other bug seems to be a DevTools issue. I'll reopen this and hope one of the CC's can figure this out.

Able to reproduce the issue on reported chrome version 71.0.3578.98 also on latest chrome 73.0.3658.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10.  
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Removing Needs-Bisect label to it.

Thanks..! 

Apparently that Cookie UI does not remove HttpOnly cookies, which causes one of the session cookies (_ib_session) to be left behind.

That seems like a bug to me, since the other cooke clearing UIs don't seem to suffer that problem -- clearing cookies using either chrome://settings/siteData, or devtools -> Application -> Clear storage, works properly with the HttpOnly cookies.

The _ib_session cookie is correctly listed in the Cookies UI but the deletion doesn't work. It fails in CookieMonster::DeleteCanonicalCookie because the candidate doesn't match the timestamp of the cookie precisely:

LOG(ERROR) << candidate->CreationDate() << " " << cookie.CreationDate();
LOG(ERROR) << candidate->CreationDate().ToDeltaSinceWindowsEpoch().ToInternalValue() << " " << cookie.CreationDate().ToDeltaSinceWindowsEpoch().ToInternalValue();
LOG(ERROR) << (candidate->CreationDate() == cookie.CreationDate());

[133266:133282:0103/115849.432504:ERROR:cookie_monster.cc(812)] 2019-01-03 10:58:43.134 UTC 2019-01-03 10:58:43.134 UTC
[133266:133282:0103/115849.432535:ERROR:cookie_monster.cc(813)] 13190986723134200 13190986723134156
[133266:133282:0103/115849.432556:ERROR:cookie_monster.cc(814)] 0

There is only a difference of a few microseconds

It looks like there are two places where the creation time is set:

1. net::URLRequestHttpJob::SaveCookiesAndNotifyHeadersComplete
https://cs.chromium.org/chromium/src/net/url_request/url_request_http_job.cc?l=789&rcl=b83a385e9debedea44c2e4549ddd81eae067bcc6

2. CookieMonster::SetCookieWithOptions
https://cs.chromium.org/chromium/src/net/cookies/cookie_monster.cc?l=736&rcl=b83a385e9debedea44c2e4549ddd81eae067bcc6

The Cookie UI receives the first date (through CanSetCookie) and the CookieStore creates its own date, which is slightly different, so they don't match when being deleted.

To solve this issue, we could use SetCanonicalCookieAsync instead of SetCookieWithOptionsAsync as we already have the cookie object.
This way the cookies would be identical. SetCookieWithOptionsAsync calls SetCanonicalCookie but it has an additional HasCookieableScheme(url) check and the time set by the CookieMonster guarantees unique timestamps (CookieMonster::CurrentTime()), so I'm not sure if we could directly replace the call? But it looks like URLRequestHttpJob is the only place left where cookies are set through SetCookieWithOptionsAsync, all other places create the cookie directly and use SetCanonicalCookieAsync.

Hm, that still doesn't fix the issue if an existing cookie is overriden. 
In this case the cookie that is supposed to be written inherits the creation date from the previous cookie but the Cookie UI also doesn't know that this happened:
https://cs.chromium.org/chromium/src/net/cookies/cookie_monster.cc?l=1278&rcl=e13b4d76b4462c5aa7de5aea65d538145013f823

mmenke, morlovich: You discussed the whole issue about deletion and timestamps in  https://crbug.com/826322 .
What do you think?

There seem to be two separate problems:
When a cookie is created, the cookie ui can have a tiny bit older timestamp than the CookieStore.
When a cookie is updated, the cookie ui receives a cookie with the new timestamp but the creation time of the older cookie would not be overridden in the CookieStore.

If we can't reflect the latest cookie value in the UI snapshot, how about deleting all cookies that match the selected one based on a subset of its properties, say (cookie domain, cookie_path, cookie name)?

Sounds good. I created a CL to ignore the CreationDate for cookie deletions: https://crrev.com/c/1396119

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

commit f18b096e2de34e724331bfa7b8d3b25eb2e1fc8e
Author: Christian Dullweber <dullweber@chromium.org>
Date: Tue Jan 08 16:29:39 2019

Ignore CreationDate when deleting a cookie

It is possible that the CookieMonster modifies the creation timestamp of
a Cookie during creation or updating and the CookiesTree UI doesn't
get notified about this. If a user later tries to delete a cookie
with a timestamp that is not consistent with the timestamp in the cookie
store, this deletion would fail.
To fix the issue, the timestamp is ignored. As we still check cookies
for being equivalent and having the same value, the property that
updated cookies shouldn't get deleted is preserved.

Bug:  918413 
Change-Id: I392e19219c612021003ef7abe99bc52cdbb23173
Reviewed-on: https://chromium-review.googlesource.com/c/1396119
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620751}
[modify] https://crrev.com/f18b096e2de34e724331bfa7b8d3b25eb2e1fc8e/net/cookies/cookie_monster.cc
[modify] https://crrev.com/f18b096e2de34e724331bfa7b8d3b25eb2e1fc8e/net/cookies/cookie_monster_unittest.cc