1856645 - Cookies set in normal window show up in cookies in devtools within Private Mode

Status: RESOLVED FIXED

(DevTools :: Storage Inspector, defect, P2)

Description

[Kuba Orlik]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Open two windows - one regular, one in private mode. Go to mozilla.org in both of them. Open Devtools in both of them, navigate to Storage. In regular mode, run document.cookie="leaks=true". Navigate to Private Mode, open the mozilla.org tree in cookies view, see that this cookie is visible there, as well.

Actual results:

The "leaks=true" cookie is visible in the devtools in the Private Mode window

Expected results:

It should be separate, cookies set in regular windows should not leak to private windows

Comment 1

[Kuba Orlik]

Attachment: Screencast showcasing the issue

Comment 2

[Kuba Orlik]

This also happens across Firefox Containers

Comment 3

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'DevTools::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Julian Descottes [:jdescottes]]

The exact STRs seem to be:

• open a tab in a regular Firefox window
• open the same tab in a Private Browsing Firefox window
• open the storage inspector in the Private Browsing Firefox window
• run document.cookie="leaks=true" in the regular Firefox window

You will see the cookie appear in the Storage inspector of the Private Browsing Firefox window. However the cookie is not actually set. If you close/reopen devtools, the leaks cookie is gone. And using document.cookie to read cookies will also not show this cookie.

So this is most likely only a UI bug where we incorrectly show the cookie in the UI and not an actual leak of the cookie between regular and private windows.

Comment 7

[Emma Zühlcke [:emz]]

I suspect it's an issue with how we listen for cookie changes. I see that devtool subscribes to both normal and private browsing cookie changes here: https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/devtools/server/actors/resources/storage/cookies.js#528
It then calls onCookieChanged here: https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/devtools/server/actors/resources/storage/cookies.js#201
but doesn't do any filtering for normal or private browsing as far as I can see? Really it should look at the cookie's OriginAttributes and compare them to the OriginAttributes of the principal of the content window the devtools instance is attached to.

Comment 9

[David Balažic]

Note: this work in other direction too. If the site in Private windows changes the cookie, the change is shown in the devtools in the normal window.

Another bug that makes Firefox less desirable for web developers.

Comment 12

[Ruhollah Majdoddin]

Attachment: Bug 1856645 - Filter cookie change notifications by the host's originAttributes in the storage actor. r=#devtools-reviewers

The cookies storage actor is a parent-process resource: one instance
per toolbox, and every instance observes both "cookie-changed" and
"private-cookie-changed". getMatchingHosts() decided whether a changed
cookie belongs to this toolbox by host string alone, so every cookie
change was forwarded to every same-host panel regardless of cookie
jar: a cookie set in a normal window shows up in a private window's
Storage panel and vice versa, and the same happens across containers
(comment 2). The panel then lists rows its own jar does not contain;
the enumeration path is already scoped by the host's originAttributes,
which is why such rows vanish on reopen and cannot be deleted.

Following the suggestion in comment 7, getMatchingHosts() now compares
the cookie's originAttributes with the originAttributes of the host's
browsing context and ignores mismatches, for privateBrowsingId and
userContextId.

partitionKey is deliberately not compared: a top-level document's
principal has an empty partitionKey while getCookiesFromHost also
collects the cookies partitioned under the site itself (from
cookieJarSettings), so a plain equality check would suppress updates
for partitioned cookies that enumeration legitimately lists. The
cross-partition case on this push path is left for bug 2060029.

The new test opens Storage panels on the same host in a normal window,
a private window and a container tab, and asserts that cookie adds and
changes appear only in the panel whose jar they belong to, in both
directions, while same-jar updates keep working.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/64d894940229
https://hg.mozilla.org/integration/autoland/rev/b3c15bc9a2a8
Filter cookie change notifications by the host's originAttributes in the storage actor. r=devtools-reviewers,jdescottes

Comment 14

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/b3c15bc9a2a8

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for the Fx155 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Possible wording:

Fixed the DevTools Storage panel showing cookies from private windows, containers, and other partitions alongside the inspected page's own cookies.

Comment 16

[Ruhollah Majdoddin]

Thanks Ryan! Nominating with your suggested wording.

Suggested wording: Fixed the DevTools Storage panel showing cookies from private windows, containers, and other partitions alongside the inspected page's own cookies.

Context: long-standing user-visible defect (reported 2023) - the Storage panel live-updated with cookies belonging to other cookie jars (private windows, containers) alongside the inspected page's own, listing rows that vanished on reopen and could not be deleted. The fix ships enabled, not behind any flag. No documentation link needed.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx155 relnotes.