New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 627256 link

Starred by 2 users
Status: Fixed
Owner:
mmenke@chromium.org
Closed: Jul 2016
Cc:
█ mkwst@chromium.org
boliu@chromium.org
█ dfalcant...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Android: CookiesFetcher::RestoreCookies doesn't work correctly.

Project Member Reported by mmenke@chromium.org, Jul 11 2016 
It increases the scope of exact-domain-match cookies to wildcard-domain-match cookies (i.e. "spam.com" exact matches becomes ".spam.com" matches).

I question the decision to implement yet another cookie store class, when net already has one, as it leads to this exact sort of issue.  It just seems like a bad idea, that's bound to result in breakages.

This looks to have been broken since it was first landed, 18 months ago.

Comment 1 by mmenke@chromium.org, Jul 11 2016 

Oh, and for the record...This class apparently created to store incognito-mode cookies after Chrome is closed, and does so by walking through all the cookies and saving them directly, and then tries to recreate them on session restore.

Comment 2 by mmenke@chromium.org, Jul 12 2016

Components: UI>Browser>Incognito Internals>Network
Labels: OS-Android

Comment 3 by mmenke@chromium.org, Jul 12 2016

Components: -Internals>Network Internals>Network>Cookies

Comment 4 by dfalcant...@chromium.org, Jul 13 2016 

Correcting the timeline in #0: Android's CookieFetcher has existed in the downstream repo since 2013:

https://bugs.chromium.org/p/chromium/issues/detail?id=295865
https://chrome-internal-review.googlesource.com/153868

Comment 5 by mmenke@chromium.org, Jul 18 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment