Closed Bug 1629658 Opened 4 years ago Closed 4 years ago

IndexedDB storage set on a subdomain of a site not cleared by "Forget About This Site"

Categories

(Toolkit :: Data Sanitization, defect, P2)

Product:
Toolkit
Component:
Data Sanitization
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1628240
Tracking Flags:
Tracking Status
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed

People

(Reporter: englehardt, Unassigned)

References

(Blocks 1 open bug)

Details

STR:

  1. In a fresh profile go to https://senglehardt.com/test/dfpi/first_and_third.html. This page sets a random value in storage ONLY IF no value already exists.
  2. Refresh the page, you should see messages that say "IndexedDB key foo already written, NOT overwriting..." in each iframe. Note the random value written to storage for the same-site, cross-origin iframe (test.senglehardt.com)
  3. Open the History manager, right click "senglehardt.com" and click "Forget About This Site".
  4. Refresh the page once more.

ER: All storage locations in the same-site, same-origin iframe (senglehardt.com) and same-site, cross-origin iframe (test.senglehardt.com)

AR: The indexedDB key in the test.senglehardt.com iframe is not reset, even though all other storage locations included in this test page are.

Also just so it's clear: this test page is meant for dfpi, but this reproduces without dfpi.

This is because we only clear subdomains for localStorage, specified by the parameter here: https://searchfox.org/mozilla-central/rev/a4d62e09a4c46aef918667fa759bf9ae898dc258/toolkit/components/cleardata/ClearDataService.jsm#561

Originally this was done to mirror the old behavior for clearing localStorage when switching to next-gen. Arguably localStorage was always doing it right and we should do the same for all quota data. That would also significantly simplify the code.

Blocks: 1102808
status-firefox75: --- → wontfix
status-firefox76: --- → wontfix
status-firefox77: --- → affected
Priority: -- → P2
See Also: → 1628240
See Also: → 1629667

Tom, was this fixed by bug 1628240?

Severity: -- → S3
Flags: needinfo?(ttung)

(In reply to Johann Hofmann [:johannh] from comment #2)

Tom, was this fixed by bug 1628240?

Yes, it should be fixed by bug 1628240 and I verify that on my Nightly build. Based on this, I am going to close this ticket and mark it as a dup of bug 1628240.

Hi Steven, could you check if the issue still exists for the latest Nightly? If so, please feel free to reopen this ticket. Thanks!

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(ttung) → needinfo?(senglehardt)
Resolution: --- → DUPLICATE

(In reply to Tom Tung [:tt, :ttung] from comment #3)

Hi Steven, could you check if the issue still exists for the latest Nightly? If so, please feel free to reopen this ticket. Thanks!

I've confirmed that this is fixed in the latest Nightly.

Flags: needinfo?(senglehardt)
You need to log in before you can comment on or make changes to this bug.