Manifest v3 compatibility #21
Conversation
Not working with the content policy right now
…in content Trying to use Worker in contentScript did not give me the right origin, but loading an iframe does? Anyway, this way we forward all requests from all frames to the background script, and then background script will forward them to a single iframe that hosts a WASMTranslationHelper. And it works! There are some opportunities to use makeServer and makeClient in other places as well I think, because this is about the 5th time I've implemented that functionality…
|
The general problem was that it was impossible to load the WASMTranslationWorker inside the background-script context. This is now solved by loading it in the tab, in an iframe in the top-most frame. Similar to how the original firefox-translations addon does it. Translation requests from all frames in a tab are then proxied through the background-script to that one iframe. Downside is that we now have 1 translator loaded per tab instead of one shared among all tabs, and that it does not survive page navigation. Performance is therefore worse than the manifest-v2 branches of this add-on. But it is similar to the Mozilla version of this add-on. So probably it is good enough… |
…lper/Worker as well
# Conflicts: # extension/controller/translation/WASMTranslationHelper.js # extension/controller/translation/WASMTranslationWorker.js
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1687778 would be helpful, although I can probably shim it reasonably easy since in Firefox effectively the worker stays in memory, so just a local variable can do this work as long as I'm not trying to sync it between the popup and the background-script. (content-script should have no access to begin with according to the spec?) |
|
I don't know what Google is doing but V3 is still a hot mess. It feels a lot like how Twitter killed their ecosystem when they turned off their API. |
|
Superseded by #73 |
Ultimately this should solve #10.