1805956 - browsingData API doesn't clear localStorage data set in private tabs

Status: REOPENED

(WebExtensions :: Untriaged, defect, P3)

Description

[rcuxecbvtdauadkxrc]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

I'm making a simple addon to delete localStorage, cookies, cache and history.
Now I'm using Firefox 108, but the problem is also on the previous version.
I tried the following two codes:

1)browser.browsingData.remove({},{
localStorage: true,
cookies: true,
cache: true,
history: true
});

2)browser.browsingData.removeLocalStorage({});
browser.browsingData.removeCookies({});
browser.browsingData.removeCache({});
browser.browsingData.removeHistory({});

Actual results:

Everything works well except for removing localStorage.
I don't know what the problem is, but on another pc with Firefox 91 both codes works properly.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (110.0a1/20221219162526), Beta (109.0b4/20221218190303) and Release (108.0.1/20221215175817) under Windows 10 x64 and Ubuntu 16.04 LTS.

For lack of a test extension I used Cookie AutoDelete in my tests (https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/).

As per Comment 0, running either or both the provided codes in the add-on console will clear everything except localStorage (part of the localStorage is cleared, but not all of it as far as I can tell for some websites, while for others it’s cleared completely and the website entry is removed from the Manage Cookies and Site Data panel). Cookies, Cache and History are all cleared without issues, on the other hand.

See the attached screenshot for more info.

Since this was initially marked as an enhancement, I’ll change it to a defect to better reflect this.

Running a mozregression spanning Firefox 91 to Firefox 108 did not reveal any regressor bug as mozregression could not find enough data to bisect and stopped. Refining the search from Firefox 91 to 92 ended up with the same result.

The corresponding pushlog is: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3880d0d21aa306cfac44ea0d0fa188b59ae4233c&tochange=e3fb9f4b3db8772e54636c30426bbbd911deb8ad

Comment 3

[Alex Cornestean]

Attachment: 2022-12-20_09h37_56.png

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

I'll take a look , needinfo-ing myself as a reminder.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

I tried to reproduce this issue locally, but it seems I may be missing something in the STR to be able to trigger it.

Similarly to what Alex mentioned in comment 2 I tried to reproduce it with "Cookie AutoDelete", but then given that clicking the extension button that is expected to clear the localStorage data was actually removing all localStorage data that was listed in the DevTools Storage panel, I also tried to reproduce it with the same API call mentioned in comment 0 by executing it from the AddonDebugging's webconsole panel.

See https://youtu.be/jc1aPShFxCo for a screencast of the STR I have been using locally.

Hey Alex (and the reporter as well),

would you mind to double-check if with the same steps I used in the screencast attached right above are you still getting data listed in the DevTools Storage panel?
(and then to try again with the STR you originally used to see if that gives you a different outcome, possibly on the 3 release / beta / nightly channels for comparison).

Comment 6

[Alex Cornestean]

Hey Luca,

I tried your STR, by first adding data to localStorage via localStorage.setItem("test",123), checking it was actually set and then removing the data via both API calls mentioned in Comment 0 from the add-on debug console (I used “Cookie AutoDelete” this time around as well).

localStorage was set for https://www.mozilla.org/en-US/ and upon performing the above steps, there was no more data for the website i.e. localStorage was cleared successfully. See first attached video.

I also set localStorage for the same website and proceeded to remove it as above and then checked in about:preferences#privacy in the “Cookies and Site Data” section by clicking “Manage Data…” as per my original approach of checking localStorage. It seems that the Storage column still lists data for mozilla.org after performing the steps. See second attached video.

Tested on the latest Nightly (110.0a1/20230109212101), Beta (109.0/20230109161414) and Release (108.0.2/20230104165113) under Windows 10 x64.

Comment 7

[Alex Cornestean]

Attachment: 2023-01-10_09h39_49.mp4

Comment 8

[Alex Cornestean]

Attachment: 2023-01-10_09h46_41.mp4

Comment 9

[Tomislav Jovanovic :zombie]

We can't precede without more info, feel free to reopen if you can provide it.

Comment 10

[rcuxecbvtdauadkxrc]

I reopen because i have new info. I tested the same code on the new 113 version and is still not working, but only if using private browsing. In non-private browsing everything is good. Don't know if is the same with other versions.

Comment 11

[rcuxecbvtdauadkxrc]

The thread was closed due to lack of new information. I reopened and provided them more than 2 months ago and no news since. Can someone help me?

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to rcuxecbvtdauadkxrc from comment #10)

I reopen because i have new info. I tested the same code on the new 113 version and is still not working, but only if using private browsing. In non-private browsing everything is good. Don't know if is the same with other versions.

I double-checked this, and I can confirm that the detail about the private browsing tab seems to be the detail we were missing from the initial STR.

I've tried the following STR:

• install cookie-autodelete extension
• open one private and one non private tab on www.wikipedia.org
• open the developer tools console tab and executed localStorage.getItem("translationHash") in both the private and non private tab to confirm the item is set to a string
• then opened about:debugging and clicked Inspect to open a toolbox for the cookie-autodelete extension background page
• in the developer tools console tab for the cookie-autodelete extension, I executed the following browsingData API call: await browser.browsingData.removeLocalStorage({ hostnames: ["www.wikipedia.org"] })
• once the API call was resolved, I executed localStorage.getItem("translationHash") in both the private and non private wikipedia tab
  and confirmed that the localStorage item was not set anymore in the non private tab but it was still set on the private tab

On the contrary cookie-autodelete "Clear LocalStorage for this domain" button (available from the extension browserAction popup window), the extension was able to clear localStorage data for both private and non-private tabs, but the extension needed to be allowed to access private tabs and the "Clear LocalStorage for this domain" button had to be triggered explicitly in both tabs (the private and non private ones) explicitly, I haven't double-checked explicitly but I suspect that cookie-autodelete is achieving this by executing a content script on the tab, which likely used the localStorage WebAPI from the webpage itself to clear the data (and not using browsingData for it).

The reason why browsingData seems to be removing the localStorage data as expected on the non private tab but not on the private one is very likely due to the fact that for a webpage loaded in a private tab the localStorage API enters a session mode which makes it work like the sessionStorage API, the data is only kept in memory and never stored on disk, and so it is very likely that the QuotaManager service (which we use internally to clear the localStorage data when the NextGen localStorage backend is being used, which is the default on all channel) is not managing that data and so it doesn't clear it neither.

I'll adjust the bugzilla subject message to better capture the actual underlying issue (e.g. by tweaking it into browsingData API doesn't clear localStorage data set in private tabs).

In the meantime, the only workaround that can be implemented on the extension side to cover this use case is likely to be the one I described above:

• using tabs.executeScript / scripting.executeScript to clear the localStorage data in the private tab through the localStorage webAPI in the webpage itself

As a side note, the localStorage data from private tabs will be cleared automatically when all private tabs have been closed, and so if there isn't any private tab opened around, than there wouldn't be any localStorage data to clear in private tabs (but if there is at least one, but not on the domain that is meant to be cleared, then the tabs hiding permission and API methods may be a way to allow the extension to still workaround the issue, e.g. by opening the private tab as hidden and then execute a content script in it to clear the data and then closing the hidden tab).