Closed Bug 1628936 Opened 2 years ago Closed 3 months ago

The devools storage inspector does not show isolated cookies when dfpi is active

Categories

(DevTools :: Storage Inspector, defect, P3)

defect

Tracking

(firefox86 fixed)

RESOLVED FIXED
86 Branch
Tracking Status
firefox86 --- fixed

People

(Reporter: englehardt, Assigned: pbz)

References

(Blocks 3 open bugs)

Details

(Keywords: regression)

Attachments

(1 file)

Dynamic First Party Isolation (Bug 1549587) isolates third-party storage by double keying the storage using the First-Party origin attribute. When dfpi is active, the Storage Panel does not show isolated cookies with the exception of the first time they are set.

STR:

  1. In a fresh profile set network.cookie.cookieBehavior = 5
  2. Visit https://senglehardt.com/test/dfpi/first_and_third.html. You'll see cookies, localstorage, session storage, and indexed db data written for three iframes from separate origins.
  3. Open the Storage Panel and note that all storage locations show the expected results.
  4. Refresh the page. No new storage is set. Instead, storage is read from all locations.
  5. Open the Storage Panel and switch between the origins listed under "Cookies". Note that englehardt-tracker.com is empty

ER:

  • The storage panel displays the active storage area for all storage locations

AR:

  • No cookies for the isolated origin (englehardt-tracker.com) when storage is only read during the page visit. This does not reproduce when the storage location is not isolated.

Thanks for filing!

I don't have exactly the same STRs, for me englehardt-tracker.com is empty even for the first visit (when the page reads Cookies not yet set, setting a new cookie...)

Priority: -- → P3

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3
Assignee: nobody → pbz
Status: NEW → ASSIGNED

The issue is here: https://searchfox.org/mozilla-central/rev/4415bec7a49c50a338167d9c8934527b9cae59d0/devtools/server/actors/storage.js#642
Cookies are queried from Services.cookies by host and OriginAttributes. For subframes the host for this call is correct, however the origin attributes are retrieved from the wrong storage principal. They come from this.storageActor.document.effectiveStoragePrincipal.originAttributes, which is the top level storage principal.

We can probably get the correct origin attributes via this.storageActor.getWindowFromHost(host).document.effectiveStoragePrincipal.originAttributes (Where host is the hostname of the frame).

For iframes it's important that we use the correct storage principal when interacting with cookies.
With dFPI enabled the origin attributes of third party contexts are different from the top ones.
This led to situations where we didn't show any cookies for storage isolated third party frames.

See Also: → 1602890
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fc32d902cd48
[devtools] Use the correct storage principal for handling cookies. r=ladybenko
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
QA Whiteboard: [qa-86b-p2]

While testing I ran into this bug again. It only breaks with dFPI enabled, see original STR in comment 0.

mozregression led me to Bug 1700904:

 6:52.58 INFO: Last good revision: 6a97950a60a6daa2275c776c817c764143806c4d
 6:52.58 INFO: First bad revision: 751d66c96a08b33f4e5b0b9dfcc29ce7bc7b2afb
 6:52.58 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6a97950a60a6daa2275c776c817c764143806c4d&tochange=751d66c96a08b33f4e5b0b9dfcc29ce7bc7b2afb

Belén, could you take a look?

Status: RESOLVED → REOPENED
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(balbeza)
Keywords: regression
Regressed by: 1700904
Resolution: FIXED → ---

Seems like this also affects indexedDB. localStorage and sessionStorage work fine.

We should add a test case to make sure we don't regress again.

Assignee: pbz → nobody

If that's ok, I'd prefer to treat the regression as a separate record (bug 1721131).

Status: REOPENED → RESOLVED
Closed: 9 months ago3 months ago
Keywords: regression
No longer regressed by: 1700904
Resolution: --- → FIXED
Flags: needinfo?(balbeza)
You need to log in before you can comment on or make changes to this bug.