Closed Bug 1628936 Opened 2 years ago Closed 3 months ago

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


(DevTools :: Storage Inspector, defect, P3)



(firefox86 fixed)

86 Branch
Tracking Status
firefox86 --- fixed


(Reporter: englehardt, Assigned: pbz)


(Blocks 3 open bugs)


(Keywords: regression)


(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.


  1. In a fresh profile set network.cookie.cookieBehavior = 5
  2. Visit 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 is empty


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


  • No cookies for the isolated origin ( 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 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

The issue is here:
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
[devtools] Use the correct storage principal for handling cookies. r=ladybenko
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:

Belén, could you take a look?

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).

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.