The cookies storage actor keys a cookie row by name, host, path and
partitionKey (#getCookieUniqueKey), leaving privateBrowsingId and
userContextId out of the key. A toolbox scoped to a single tab never
mixes those jars in one listing, but in an everything-scope session
(the Browser Toolbox) one host entry aggregates every jar backing the
host, and two same-named cookies at the same host and path in
different jars collapse into a single row. The listing shows one of
the two cookies, and which one is unstable: a cookie change keeps the
last-changed cookie while re-listing the host keeps the last jar in
enumeration order. The edit and delete paths resolve the row back to
nsICookies with the same jar-blind fields: deleting the row removes
the cookie from every jar backing the host, and editing the row
modifies the first match, which can be a different jar than the one
whose value the row displays.
Build the key's last slot from
ChromeUtils.originAttributesToSuffix(cookie.originAttributes) instead
of the bare partitionKey, so the key carries the cookie's complete
jar, and compare the same suffix in editCookie() and _removeCookies()
when resolving a row back to a cookie, so edit and delete act on
exactly the cookie the row shows. A default-jar cookie's suffix is
the empty string, so keys of ordinary cookies are unchanged. The key
stays opaque to the client: nothing outside the actor parses it, and
the Storage panel's Partition Key column reads its own field.
browser_storage_cookies_all_jars.js grows a same-name scenario: a
cookie with the same name in the normal, private and container jars
must surface as three distinct rows, deleting one row must remove
only its jar's cookie, and editing one row must modify only its
jar's cookie. The getCookieId test helpers now take the cookie's
originAttributes and derive the suffix, and the tests addressing
rows in non-default jars pass theirs.
Differential Revision: https://phabricator.services.mozilla.com/D316768
Ruhollah Majdoddin
b5810926a9