I have a reduced test-case;

1. Open devtools and record activity in the network panel
2. Visit https://crbug-703485.glitch.me/
3. Click on the request for crbug-703485.glitch.me and click on the cookies tab
4. Note two response cookies - select the first by clicking on it
5. Use the difference in the size column to differentiate the otherwise identical cookies
6. Sort by the size column multiple times - note that the selected cookie moves from the first response cookie to the second (and last), and despite the cookies being re-ordered by the sort the last cookie is always selected

Expected outcome;
1. As the originally selected cookie is selected, it should remain selected whilst its position changes in the table

I would be happy to provide a CL for this, if it's agreed that action should be taken. _isSameCookie in third_party/WebKit/Source/devtools/front_end/cookie_table only compares the cookie name, domain and path at present.

 

Deleted: crbug-703485.webm 866 KB

	crbug-703485.webm 866 KB View Download

Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest stable #57.0.2987.110 by following steps mentioned in the comment #3.
Observed the selected cookies doesn't remain selected by sorting the cookies.

This issue is observed in older version of chrome M35-35.0.1849.0 as well. Hence marking it as untriaged.

TL;DR
It's better to not do anything than to have a high chance of breaking things.



So, I created a patch that should have resolved this issue (https://codereview.chromium.org/2823103002/), but we decided not to proceed with it.

The problem comes down to the cookies being exactly the same, so the DataGrid does not have a key to uniquely identify the entry to restore the selection. DataGrid is an area we do not like modifying because it's a growing problem area and every time we touch it, it breaks things and often ends up making it even worse. We have plans on eventually rewriting our DataGrid component, but it's not easy and we have lots of edge cases.

In looking into this bug, I did discover that the reason this was even visible to the user was because we show two inconsistent sizes for the exact same cookie data. This was because of a few things...

Headers can contain a single Set-Cookie header with multiple cookies being set or multiple Set-Cookie headers setting multiple cookies. To handle this easier, we split the cookies up then concat them back together with "\n". This then gives us an easy string to parse, however in reality there will always be an extra "\n" to terminate the header entry.

This then causes the parser to consider the last cookie to not have any terminating character and one cookie will always be -1 byte than the rest.

The question then becomes:
Do we consider "\n" characters to be a part of the cookie or header or both?
Which cookie do we consider the ";" to be a part of (right or left [if exists])?

We ended up deciding not to do anything about this right now because we are afraid we will break things. Part of this data is accessible via chrome's extensions. If we change this logic to be what we think is "correct", then extensions might break.

We are going to mark this as WontFix because of this, but when DataGrid gets fixed it'll at least fix this particular issue.