1673477 - Enable crossOriginIsolated and use of SharedArrayBuffer for Extension pages

Status: REOPENED

(WebExtensions :: General, enhancement, P3)

Description

[stoically]

Trying to use SharedArrayBuffer on an arbitrary extension page results in Uncaught ReferenceError: SharedArrayBuffer is not defined. Also crossOriginIsolated says false. I'd expect extension pages to be secure contexts.

According to MDN it'd need to set to Cross-Origin Headers accordingly, but that doesn't work for extension pages.

Maybe Bug 1575625 is related

Comment 1

[Kris Maglione [:kmag]]

That's because extension pages aren't cross-origin-isolated. All extensions currently run in the same process.

Comment 3

[Rob Wu [:robwu]]

I'm re-opening this bug, to let it serve as the issue to track enabling SharedArrayBuffer more broadly. It is currently only enabled to privileged extensions (bug 1674383).

Chrome allows extensions to opt in to SharedArrayBuffer when their manifest.json specifies cross_origin_embedder_policy and cross_origin_opener_policy.

• Chrome's implementation bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1199491
• Chrome's design doc: https://docs.google.com/document/d/1c6SX3fsp7x1BlzpCPvYSKPtjjT56W4DpoOKPSXmLllo/edit
• Documentation for COEP: https://developer.chrome.com/docs/extensions/mv3/manifest/cross_origin_embedder_policy/
• Documentation for COOP: https://developer.chrome.com/docs/extensions/mv3/manifest/cross_origin_opener_policy/

Comment 4

[Daniel Veditz [:dveditz]]

Hope you don't mind me re-writing the summary to sound like the new feature work it would be.

Comment 5

[Vince Scafaria]

Reading the footnote to the google doc that Daniel linked, it says "Extension processes are isolated now. See https://bugs.chromium.org/p/chromium/issues/detail?id=1209417". I saw a lot of activity from 2021 but am unclear on the current blocker (though confess I am just an extension developer, not a Mozilla expert, so an explanation geared toward a non-expert would be welcome). Is it a prioritization question or does it still bear the same complexity described as of 2021?

It would be awesome to reach parity with Chrome's ability to host SQLite via OPFS in the browser. Our non-profit is building a suite of apps meant to help individuals to own, control, analyze, and use their own data without having to rely on trusting third-party servers (since end-users don't tend to run servers of their own). SQLite in the browser via OPFS would allow powerful local-first, private-by-design application models. Thank you!

Comment 6

[Rob Wu [:robwu]]

(In reply to Vince Scafaria from comment #5)

Reading the footnote to the google doc that Daniel linked, it says "Extension processes are isolated now. See https://bugs.chromium.org/p/chromium/issues/detail?id=1209417".

Dan just linked the tickets and doc I mentioned in comment 3. All of that information is specific to Chromium, but the reasoning and API design is relevant to other browsers as well.

I saw a lot of activity from 2021 but am unclear on the current blocker (though confess I am just an extension developer, not a Mozilla expert, so an explanation geared toward a non-expert would be welcome). Is it a prioritization question or does it still bear the same complexity described as of 2021?

I don't know what you are referring to. In any case, the curent status in Firefox is:

• in bug 1674383, we offered SharedArrayBuffer to privileged extensions.
• Extensions in Firefox run in a separate process.
• All extensions share the same process.
• To support crossOriginIsolated and SharedArrayBuffer, we would have to support multiple processes, at least for extensions that opt in to COEP/COOP.

Comment 7

[Justin Mayfield]

This will prevent me from migrating my extension from IDB to Sqlite3/OPFS.

Comment 11

[Vince Scafaria]

Hi, just checking back to better understand status/timing for this to allow use of Sqlite3/OPFS in a Firefox extension. Any estimate available? Thanks!

Comment 12

[xsilverkinx]

Any news on this? Waiting 2 years for implementation of this feature :(

Comment 13

[intothevoid005]

Any updates? There is an extension that is on chrome that i really want to use on firefox but the dev says this needs to be implemented first.

https://sites.google.com/view/history-trends-unlimited/faq#h.p_919uTSRmqHZ_

Comment 14

[jsjsketch]

Hi guys any updates on this? Given Google's decision to phase out MV2 extensions. I plan to move back to Firefox.

However, there's one crucial extension, History Trends Unlimited, that I rely on heavily and unfortunately, it doesn't have a Firefox version due to this bug.

I would appreciate it alot if someone steps in!
Thanks for reading!

7. Will you make a version of the extension for Firefox?

Yes, once it is possible to do so. Keep an eye on Firefox issue 1673477. Once it is fixed, I should be able to port this extension to Firefox.
And please see FAQ #11: The extension is closed source, so forks are not allowed.

https://sites.google.com/view/history-trends-unlimited/faq?authuser=0#h.p_919uTSRmqHZ_

Comment 15

[Wolpi]

I also wanted to ask, if there are any news regarding this feature. Thanks already!

Comment 16

[historyunlimited]

+1

Comment 17

[Lucas Eichhorn]

Concrete use case from a Firefox MV3 extension shipping local neural TTS:

read-aloud-fork integrates Supertonic 3, a small diffusion-based text-to-speech model, running in-extension via onnxruntime-web. The extension already ships the multi-threaded WASM build (ort-wasm-simd-threaded.wasm) and declares

"cross_origin_opener_policy": { "value": "same-origin" },
"cross_origin_embedder_policy": { "value": "require-corp" }

in manifest.json. In Chromium this enables crossOriginIsolated and the model runs on multiple WASM threads. In Firefox the keys produce only

Reading manifest: Warning processing cross_origin_embedder_policy:
An unexpected property was found.

so self.crossOriginIsolated stays false, SharedArrayBuffer is unavailable, and onnxruntime-web silently falls back to a single thread.

Measured impact on a recent mid-range CPU (Linux, Firefox 121+):

• per-chunk synthesis: ~10-18 s wall-clock (single thread)
• per-chunk playback: ~3-8 s
• synthesis is ~1.5-2x slower than realtime audio rate

Net effect: a several-second pause between paragraphs every time the prefetch pipeline empties out. The same extension on Chromium has no audible pauses because multi-threaded inference keeps up with playback.

Beyond this single extension, this gap is increasingly relevant: local inference (TTS, OCR, embeddings, small LLMs, image captioning) is moving into browser extensions, and onnxruntime-web / transformers.js / wllama all benefit substantially from threaded WASM. Without COI support, Firefox extensions remain structurally slower for these workloads than their Chromium counterparts, which is a meaningful disincentive for extension developers choosing a target platform.

Two observations that may help prioritization:

1. The manifest keys are already a no-op warning today. Even just honoring them at parse-time and exposing crossOriginIsolated for those pages would unblock most ONNX/WASM-threading use cases - full per-extension process isolation (bug 1827085) is a stronger guarantee but not strictly required for the basic SAB capability.

2. From an extension author's perspective, COEP/COOP in the manifest is the documented Chrome path; silently ignoring those keys leads people to assume their build is at fault rather than the platform. A clearer warning ("not yet supported in Firefox, see bug 1673477") would at least save debugging time.

+1 from another developer hitting this. Happy to provide a minimal reproducer with measurements if useful.

Comment 18

[Rob Wu [:robwu]]

I presume that the feature requests are about using SharedArrayBuffer with threads (which is restricted to cross-origin isolated pages), not SharedArrayBuffer itself. The SharedArrayBuffer constructor is indirectly available already (see SharedArrayBuffer API availability on MDN,, but its use is limited without the ability to share them across threads.

The restrictions for sharing SharedArrayBuffer is to defend against the Spectre class of side-channel attacks. Process-level isolation from other origins is therefore a prerequisite to enabling this functionality, i.e. bug 1827085.

bug 1827085 is a heavy lift. A work-around for now is to load a web page with COOP/COEP enabled and spawn workers and SharedArrayBuffer there. This is not a great work-around, but the only option for extension developers within the current constraints.

Comment 19

[ariel deschapell]

Hello, very interested in seeing this bug finally resolved. Adding another concrete use case: peerd (https://github.com/NotASithLord/peerd), a browser-extension agent harness, runs x86-Linux-on-WASM VM sandboxes (using CheerpX) and threaded WASM inference in extension pages. Both require SharedArrayBuffer. I declare the COOP/COEP manifest keys and this works on Chromium. On Firefox the same extension page gets crossOriginIsolated === false and the VM cannot boot, while the identical runtime works fine in a regular Firefox web page served with COOP/COEP headers. Today the practical workaround is re-hosting the runtime on a web origin and bridging it back with a content script, which is worse for security, offline use, and self-containment. This makes Firefox extremely hampered for AI sandboxes compared to Chromium and I'd prefer the root issue be addressed than have to maintain a strictly worse workaround just for Firefox compat.

Comment 20

[Rob Wu [:robwu]]

This feature request also came up in the WECG: https://github.com/w3c/webextensions/issues/1039

Recently we added support for the sandbox key in manifest.json (bug 1685123). Such pages do not have special extension capabilities, so in theory it would be safe to expose crossOrigin-isolated APIs such as SharedArrayBuffer there. We could consider adding a flag to support COOP/COEP in such documents, if we are far away from such support in regular extension documents.

Note: crossOriginIsolated implies separate browsing context groups. That would rule out the possibility of embedding a sandboxed page in the background page, at best an extension can only open a sandboxed extension page in a new tab and interact with it.