Communication with noscript for security settings not working in nightlies

added TorBrowserTeam201908R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff68-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac sponsor::44-can in Legacy / Trac status::closed in Legacy / Trac tbb-9.0-must-alpha in Legacy / Trac type::defect in Legacy / Trac labels

Trac:
Keywords: N/A deleted, tbb-9.0-must-alpha, TorBrowserTeam201908 added

Tagging with Sponsor 44

Trac:
Sponsor: N/A to Sponsor44-can

The issue has to do with a indexedDB error (InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.), which is thrown when noscript tries to store something via browser.storage.local API (when it receives the setting change message from torbutton). This API moved to a indexedDB implementation in 62.

I tracked down the cause of indexedDB not working to the quota manager service clearing (Services.qms.clear()) in torbutton. This is done on startup and on New Identity.

I can reproduce this also on Firefox 68:

Create a new profile.
Install noscript from AMO.
Set dom.quotaManager.testing pref to true.
Call Services.qms.clear() in console.
Set dom.quotaManager.testing pref to false.
Open debug addon window for noscript in about:debugging.
Run browser.storage.local.set({foo:bar}), it should throw InvalidStateError: A mutation operation was attempted on a database that did not allow mutations..

I think this does not affect indexeddb itself, but just the browser.storage.* implementation that uses indexeddb internally. I suspect Services.qms.clear() must be clearing some internal indexedDB data that is preventing the webextension storage API from working properly.

Not sure if this is really a bug from Firefox side, since probably we should not be calling Services.qms.clear() directly. But perhaps we can file one.

So we can solve this by not calling Services.qms.clear() (do we still need it? was it just for asm.js?). Or we can set extensions.webextensions.ExtensionStorageIDB.enabled to false, to use the previous non-indexedDB backend for browser.storage.*.

Trac:
Status: new to needs_information

Replying to acat:

The issue has to do with a indexedDB error (InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.), which is thrown when noscript tries to store something via browser.storage.local API (when it receives the setting change message from torbutton). This API moved to a indexedDB implementation in 62.

I tracked down the cause of indexedDB not working to the quota manager service clearing (Services.qms.clear()) in torbutton. This is done on startup and on New Identity.

I can reproduce this also on Firefox 68:

Create a new profile.

Install noscript from AMO.

Set dom.quotaManager.testing pref to true.

Call Services.qms.clear() in console.

Set dom.quotaManager.testing pref to false.

Open debug addon window for noscript in about:debugging.

Run browser.storage.local.set({foo:bar}), it should throw InvalidStateError: A mutation operation was attempted on a database that did not allow mutations..

I think this does not affect indexeddb itself, but just the browser.storage.* implementation that uses indexeddb internally. I suspect Services.qms.clear() must be clearing some internal indexedDB data that is preventing the webextension storage API from working properly.

Not sure if this is really a bug from Firefox side, since probably we should not be calling Services.qms.clear() directly. But perhaps we can file one.

Please do.

So we can solve this by not calling Services.qms.clear() (do we still need it? was it just for asm.js?). Or we can set extensions.webextensions.ExtensionStorageIDB.enabled to false, to use the previous non-indexedDB backend for browser.storage.*.

Good questions. I don't know the answers without looking closer. Maybe we could file a ticket for that? Sounds like we should go with the other option for now. What are the drawbacks for that one?

In-memory IndexedDB is not ready. In-PBM too. Of course, extensions.webextensions.ExtensionStorageIDB.enabled for now.

In-memory IndexedDB is not ready. In-PBM too. Of course, extensions.webextensions.ExtensionStorageIDB.enabled for now. I don't think in-memory indexeddb will be used in webextensions, it will always persist.

Sounds like we should go with the other option for now. What are the drawbacks for that one? AFAIK the old implementation is synchronous and writes the whole key-value store to disk every time there is some change. But for reasonable usage of the storage (which noscript and https everywhere probably has) this should not be a problem.

There is some migration code that is ran when extensions.webextensions.ExtensionStorageIDB.enabled which might be removed in the future, but I think that should not be an issue at least until next ESR.