Could you provide a net-internals dump? Instructions here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Hello, the dump include personal cookies, how can I safely share it with you?

Are you using your test app at localhost:8000? Could you use a fake test account whose cookies don't matter?

Hello again, 
I've looked into the dump and there are also other sensitive data like to google  cookies and other information I'd rather not to share publicly. Is there any way I could send you a private email?
Btw I could see the duplicated cookie in the dump

I see. You can send it to my email: xunjieli@chromium.org.

Attaching Internals>Network>Cookies label.
In the netlog dump, the first 5 requests to localhost do not have duplicated cookies. The 6th request sends one additional set of cookies (sessionid, csrftoken, etc) in additional to what the first 5 requests were sending.

leonard.gentitle@: since this is a recent regression, is it possible to launch your test app somewhere, so I can reproduce and do a bisect? Or if you prefer to keep it confidential, you can do a bisect. Instructions here: http://dev.chromium.org/developers/bisect-builds-py 

[+mkwst, +jww]

Are they actually distinct cookies? That is, do they have distinct paths or domains?

xunjieli@: Could you share the dump with me?

mkwst@: The reporter did a local bisect, but he didn't get the commit range.
He tried "python bisect-builds.py -a mac -g 378081 -b 382459 --use-local-cache", and could not reproduce the bug. He got the message: 
You are probably looking for a change made after 382449 (known good), but no later than 382459 (first known bad). He thinks the regression might be around 382459. 

I will share it with you once I get a confirmation from him.

51.0.2686.0 maps to 382218, which does not include revisions around 382459, so presumably that range is incorrect.

mkwst@: I have shared with you the net-internals dump through email.

My bad, I ran the bisect again with:

python bisect-builds.py -a mac -g 378081 -b 382218 --use-local-cache --user-data-dir=/path/to/user/dir

And I got again the same "You are probably looking for a change made after 382217 (known good), but no later than 382218 (first known bad)."

I have used the same User folder of the profile causing the problem. I just want to highlight again: in the version causing the issue (51.0.2686.0) the problem is reproducible only with the specified user profile (synced with google account). If I change user profile or I chose incognito mode then I cannot reproduce the issue.

I did disabled (not removed) all the extensions, could it be that they could still create troubles?

Just checking, is there any update on this? This is still happening on 52.0.2715.0 canary (64-bit) Mac Osx 10.9.5

52.0.2730.0 canary (64-bit), still happening, could please someone gives an update on this? If this lands in stable will break many applications

For a while this problem went away, I'm not sure why but today it's back, on Mac Version 56.0.2908.0 canary (64-bit). See the attached file for an example of a request setting duplicate cookies.

Could someone gives me an update on this? This is breaking my application, because it sets old expired cookies and the users will be logged out each time even if they have valid cookies!!

Deleted: duplicate_cookies.txt 999 bytes

duplicate_cookies.txt 999 bytes View Download

Could you go to the page that gets double cookies in chrome, click on the icon on the left of Chrome's address bar, click the "cookies" button, and see if two cookies with the same name are set on different paths/domains?

no, just one set of cookies. But once( I can't reproduce it) I've seen two set of cookies (duplicated) on the same path, but I can't be 100% sure until I could reproduce this.

We are experiencing this issue on the latest live chrome browser, the request to our servers have duplicate cookies causing outages.

NVM they have different paths

Closing as per #19. This seems to be WAI.