Google Chrome

[jelmervdl]

Can we bring this extension to Chrome (and other Chromium based browsers) as well?

Service workers replace background pages.

Source: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#feature-summary

Oh dear. This has me worried.

Once it has been loaded, an extension's service worker generally keeps running as long as it is performing an action, such as calling a Chrome API or issuing a network request.

Source: https://developer.chrome.com/docs/extensions/mv3/service_workers/

The background script will not unload until all message ports have shut.

Source: https://developer.chrome.com/docs/extensions/mv3/service_workers/

Oh, that might be our way out. Our current content script has an open port for the full period it is loaded. But I have a feeling that Chrome might crack down on such behaviour.

Connecting to a native messaging host using chrome.runtime.connectNative() in an extension's service worker will keep the service worker alive as long as the port is open.

Source: https://developer.chrome.com/docs/extensions/whatsnew/#m100-native-msg-lifetime

Oh good. That's at least a bit hopeful, even though that has been introduced in 9 February, 2022 and talks about Canary. So I'm not expecting this in mainline anytime soon.

Technically most parts of this extension can run in the content-script but then you'd have TranslateLocally started separately for every iframe and that's just insane. Or TranslateLocally would have to do some tmux-like magic where it can spawn its own daemon and connect to it somehow but don't even think about going down that route.

Other scary bug reports:

• Issue 1173354: wasm does not work in extensions manifest v3 last comment from 18 feb 2022. Basically running WASM inside an extension context is locked behind a feature flag that's only in Canary at the moment, and no plans on enabling it by default yet. However, you can't upload manifest-v2 extensions anymore. So anyone using WASM in their extension is unable to update it right now.
• Migrating from background pages to service workers

… Browsers are like the TSA: in name of security you can barely do anything anymore.

[jelmervdl]

New v3 problem: Web workers do not seem to be available inside the ServiceWorker that's now responsible for the background_script. Right now, I run the WebAssembly instance inside a Worker to stay able to respond to things like translation and model list requests. (WebAssembly calls are blocking, calls to the Worker are through message passing.)

[kpu]

Or TranslateLocally would have to do some tmux-like magic where it can spawn its own daemon and connect to it somehow but don't even think about going down that route.

This actually seems like desirable functionality in the long term, if complicated to implement. Desktop application, browser, word all contacting a shared translation model process. Might also tie in with OS sandboxing. In Linux, I'd just send the stdin/stdout file descriptors as ancillary data over UNIX socket to the master daemon process then close the wrapper process. In windows, this is apparently not possible: https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

[kpu]

Windows equivalent to move file descriptors: https://lackingrhoticity.blogspot.com/2015/05/passing-fds-handles-between-processes.html

[jelmervdl]

Current plan for Chrome support:

• Rewrite state management to use chrome.storage.session storage in Chrome and some shim for it (using message passing + stateful background script) in Firefox. Change events of this storage replaces the UpdateRequest and Update messages. Slightly annoying because it is a key-value store, not full-on objects with nested change listening.
• Popup doesn't need to communicate with background script, can use state management directly to communicate progress
• background script basically does nothing more than noticing tab unload to clean up state
• Run WASM translation in the main tab, like the Mozilla extension. Let other frames communicate with it through message passing. (But we should still run it in background script on Firefox?)
• Run lang-id in main tab using i18n.detectLanguage (as is done now, but loading fasttext on every page load would be much)