Background Page LocalStorage is cleared along with site storage

UNCONFIRMED
Unassigned
(NeedInfo from)

Status

()

Toolkit
WebExtensions: Untriaged
P2
normal
UNCONFIRMED
10 months ago
2 hours ago

People

(Reporter: M8R-p7, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

49 Branch
dev-doc-needed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged)

Attachments

(1 attachment)

619 bytes, application/x-zip-compressed
Details
(Reporter)

Description

10 months ago
If a user has their Privacy preferences set to clear cookies/site data on exiting the browser, WebExtensions also lose their background page's localStorage data. I understand from IRC #webextensions that this is undesired behavior.

STR:
0. Create a new profile.
1. Install a WebExtension that writes to localStorage from a background script.
2. Check that data written to localStorage persists across restarts.
3. Go to the Privacy Preferences page (about:preferences#privacy)
4. Choose 'Use custom settings for History' and select 'Keep until: I close (browser)'
5. Check that data written to localStorage persists across restarts.

Actual Results:
The addon data persists only when websites are allowed to persist data.

Expected Results:
The addon data should persist even if website data is discarded.
(Reporter)

Comment 1

10 months ago
Created attachment 8805175 [details]
bug1313401_localstoragetest.zip

Testcase WebExtension. It reads any data currently stored in its LocalStorage and prints it to the console, then updates it with the current time.

Comment 2

10 months ago
per triage check if happens in indexdb as well.  at very least need doc depending upon action.
Priority: -- → P2
Whiteboard: [design-decision-needed] triaged

Comment 3

10 months ago
Note that the problem here is that the setting in question puts us into permanent private browsing mode, which also applies to all extension contexts.

If/when we implement split incognito mode, this probably becomes a non-issue. In the mean time, we could force background page docshells to be non-private, but I'm not sure whether or not that's actually desirable.

Comment 4

9 months ago
I think probably the best thing we can do here is provide some documentation for extension authors. 

I couldn't spot anything in MDN that suggested to extension authors when they should use which kind of storage, currently there's storage.local, storage.sync and the web APIs that could all be used. Would it be a good idea to detail that out and the implications for things like private browsing?
Flags: needinfo?(wbamberg)
Keywords: dev-doc-needed
Whiteboard: [design-decision-needed] triaged → triaged
Yes, this sounds like a good idea. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1317797.
Flags: needinfo?(wbamberg)

Updated

9 months ago
Duplicate of this bug: 1321419
> I think probably the best thing we can do here is provide some documentation for extension authors. 

Although I do think this should be documented, FWIW I don't agree that this is "the best thing we can do here".

I think private browsing, clearing history &c is generally understood to be about clearing data stored by websites, and I don't think add-ons are like websites, they are more like a part of the browser. It just happens that they use many of the same APIs as websites, because those APIs are familiar.

Put another way, it seems inconsistent to clear data for localStorage but not for storage.local.

By clearing this data, we make the APIs effectively unreliable for add-on authors - some percentage of their users will just think their add-on is broken. This isn't so bad for localStorage (although it is a footgun), because they can use the storage API instead. But it seems worse for IndexedDB, that doesn't have an equivalent WebExtension API.

Comment 8

6 months ago
(In reply to Will Bamberg [:wbamberg] from comment #7)
> I think private browsing, clearing history &c is generally understood to be
> about clearing data stored by websites, and I don't think add-ons are like
> websites, they are more like a part of the browser. It just happens that
> they use many of the same APIs as websites, because those APIs are familiar.
> 
> Put another way, it seems inconsistent to clear data for localStorage but
> not for storage.local.

The difference is that storage.local is shared between private and non-private windows. localStorage is a web API, and is different between private and non-private windows the same way that it is for other web content.

> By clearing this data, we make the APIs effectively unreliable for add-on
> authors - some percentage of their users will just think their add-on is
> broken. This isn't so bad for localStorage (although it is a footgun),
> because they can use the storage API instead. But it seems worse for
> IndexedDB, that doesn't have an equivalent WebExtension API.

Yes, that's particularly unfortunate for permanent private browsing, since there's no way around it. For other cases, extensions need to make sure IndexedDB code is running in a non-private window when the data needs to be permanent.
> localStorage is a web API, and is different between private and non-private windows the same way that it is for other web content.

Going by Bug 1277686 and https://developer.chrome.com/extensions/manifest/incognito, the incognito mode for all Webextensions is "spanning", and so *all* storage for WebExtensions (including localstorage and IndexedDB) should be shared across private and non-private windows. If it isn't, that's a separate bug.

> the setting in question puts us into permanent private browsing mode

Permanent private browsing mode is activated by the separate "Always use private browsing mode" checkbox / browser.privatebrowsing.autostart pref. 'Keep until browser close' sets network.cookie.lifetimePolicy to 2, hence is completely separate. 

Looking at 
https://dxr.mozilla.org/mozilla-central/rev/3e166b6838931b3933ca274331f9e0e115af5cc0/dom/base/nsContentUtils.cpp#9048
it seems easy enough to add an exception for "moz-extension", similar to "about" and the system (chrome) principal.
This is listed by the uBlock dev as an issue for them. https://github.com/gorhill/uBlock/issues/2795
Blocks: 1309926
Flags: needinfo?(kmaglione+bmo)
You need to log in before you can comment on or make changes to this bug.