SQLite via OPFS for Chrome Extension isn't quite supported

[vsjc91]

I was surprised to learn that use of SQLite via OPFS in a Chrome Extension currently requires launching a dedicated html page. It evidently can't be invoked from a content.js or background.js file. The S/O Q&A is here and the Chrome Extension developer group Q&A is here. Addressing this issue would unlock many exciting local-first data-intensive use cases.

[tomayac]

The core ask here is to make the following feature detection return true:

if (self instanceof ServiceWorkerGlobalScope && 'createSyncAccessHandle' in self.FileSystemFileHandle.prototype) {
  // OPFS in `ServiceWorkerGlobalScope` (extension service worker) is supported!
}

[hanguokai]

I think it makes sense that createSyncAccessHandle() is only available in Web Worker (not in Service Worker), because it returns an object that supplies sync I/O methods.

Option 1: Extension service worker supports createSyncAccessHandle

One extension only has one service worker. Ideally, SQLite WASM should run in a separate thread as a database service.

Option 2: Extension service worker supports creating Web Worker

This was proposed in #287 . But the life cycles of service worker and web worker are not coordinated.

Option 3: Use a persistent offscreen document as a database service

Use offscreen api to create a dedicated and persistent offscreen document as a database service. I say "persistent" because it's very inefficient to keep creating and destroying WASM databases repeatedly. But it is not sure if browsers will allow this.

[a-sully]

Yeah the inability to create a FileSystemSyncAccessHandle from a Service Worker is a more broad problem than just for extensions. It would be nice to see a more general-purpose solution like what's proposed in whatwg/html#8362 (see my recent comment: whatwg/html#8362 (comment))

[oliverdunk]

Adding neutral: chrome Not opposed or supportive from Chrome for now.

We're definitely excited about the idea of extensions using OPFS. With that in mind, we have just added a new reason to offscreen documents to allow spawning a worker: https://chromium.googlesource.com/chromium/src/+/a8fe947f9d5737f4e36fe32ab8fa851ea6da8865. This was in direct response to feedback about wanting to use the OPFS SQLite implementation in extensions.

On the broader discussion of giving extensions access to spawning nested workers or createSyncAccessHandle, I think there is general interest in exploring this. However, we are also conscious that the more extension service workers diverge from web service workers, the harder this makes understanding the capabilities of each.

Additionally, I promised in the last meeting to follow-up on why createSyncAccessHandle wasn't initially made available in service workers. To summarise:

• createSyncAccessHandle allows blocking, synchronous access. This is not desirable in service workers since they are built around the assumption they are always available to process events and can do so reasonably quickly.
• For SQLite, createSyncAccessHandle is important because it is the only way to achieve locking behaviour where you are guaranteed that two processes are not trying to write to the same database at the same time, which could lead to corruption.

[Progdrasil]

While very exciting to see that Chrome has support for spawning workers from an offscreen document, what is concerning is that other browsers are going different routes. As far as we understand, both Safari and Firefox have not implement offscreen documents and Safari is going towards limited event pages instead.

This fragmentation is very concerning from 1Password's point of view since these methods are very different and can affect the foundations of an extension. We're looking for a cross-browser single-codebase solution for adopting OPFS and SQLite.

Is Safari and Firefox planing to support the same work-around as Chrome?