Open Bug 1595431 Opened 5 years ago Updated 2 years ago

browsingdata.remove removes browsing data from subdomains of hostnames passed

Categories

(WebExtensions :: General, defect, P3)

70 Branch
defect

Tracking

(Not tracked)

People

(Reporter: contact, Unassigned)

References

Details

Attachments

(1 file)

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

Steps to reproduce:

Go to test.vukmirovic.org.
It will print LocalStorage: Not found...
Refresh
It will print LocalStorage: Found!
Load example extension that calls
browser.browsingData.remove(
{ "hostnames": ["vukmirovic.org"] },
{ "localStorage": true },
);
every 5s from https://github.com/wooque/test-browsingdata
Refresh page after 5s
It will print LocalStorage: Not found...

Actual results:

Subdomain LocalStorage got removed when browsingData.remove got called to remove LocalStorage for base domain.

Expected results:

Subdomain LocalStorage should stay intact when when browsingData.remove got called to remove LocalStorage for base domain.

Flags: needinfo?(lgreco)

We need to investigate this.

If "hostnames" turns out to behave as you describe (then it should have been called "domains"), then we can consider introducing the "origins" option (because that behaves in the way you requested, and is also supported by Chrome).

I took a look into this issue and it seems to only affect the browsingData API when the LSNG (nextGen LocalStorage) is disabled, but it seems to be working as expected when it is enabled (currently the defaults on Nightly):

LSNG is still disabled in 73 (See Bug 1608449), but it still doesn't seem worth to me to look into fixing the issue on the old localStorage implementation, and so I'm going to add Bug 1599979 (Enable LSNG on Release) as a dependency for this bug.

In the meantime I'm also going to attach to this issue a patch which adds an assertion to explicitly verify this scenario as part of our automated tests.

Depends on: 1599979
Flags: needinfo?(lgreco)
Assignee: nobody → lgreco
Priority: -- → P2

As mentioned in comment 2 this issue is going to be fixed once LSNG becomes the default on the release channels.

In the meantime I'm going to land the test case attached to this issue, to prevent the behavior from regressing on LSNG, but I'm adding the leave-open keyword to keep this issue open until Bug 1599979 is being marked as fixed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: leave-open
Status: NEW → ASSIGNED
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/dde426d9e47d Add test case to verify that browsingData.remove clears localStorage only for the given hostname. r=mixedpuppy
Component: Untriaged → General

The leave-open keyword is there and there is no activity for 6 months.
:rpl, maybe it's time to close this bug?

Flags: needinfo?(lgreco)

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #7)

The leave-open keyword is there and there is no activity for 6 months.
:rpl, maybe it's time to close this bug?

The leave-open keyword was added to avoid to have this bug auto-closed when we landed the additional test case attached to this issue,
I'll remove it because we don't need it to stay set at the moment.

Nevertheless, I'm not closing the issue because the bug is still not fixed, it will be fixed once LSNG is enabled on all channels (which is tracked by Bug 1599979, linked to this issue as a dependency).

Flags: needinfo?(lgreco)
Keywords: leave-open

As mentioned in comment 8 this bug is meant to be closed once LSNG has been enabled on all channels (Bug 1599979).

Bug 1599979 doesn't have a priority set, but Bug 1711922 is tracking a staged rollout and its priority is set to P3.

In the meantime, I'm clearing the assignment (to reflect that none of us is actively working on this anymore, and it is just waiting for the fix to reach release) and changing the priority to P3.

Assignee: lgreco → nobody
Severity: normal → S3
Status: ASSIGNED → NEW
Priority: P2 → P3
See Also: → 1711922
See Also: → 1797376
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: