Closed toasted-nutbread closed 3 years ago
Are you currently using chrome.tabs.executeScript({code: '...'}), eval(), or new Function() in background contexts or content scripts?
- Move all external code (JS, Wasm, CSS) into your extension bundle.
- Update script and style references to load resources from the extension bundle.
- Use chrome.runtime.getURL() to build resource URLs at runtime.
This will present an issue with Handlebars.js, since it uses
Function
constructor to dynamically eval code.
This is quite worrying since custom Handlebars templates can be very important to some users. I wonder if there's a fork fixing the issue. https://github.com/handlebars-lang/handlebars.js/issues/1443#issuecomment-591072032
- Service workers have no DOM, so the
clipboardPasteTarget
shenanigans won't work. Not sure what the workaround for that would be.
navigator.clipboard.readText
will work on Firefox, but on Chrome it will be quite useless because they don't allow reading clipboard in the background. Since the manifest is still not finalized, I think we should search the bug tracker for any issues mentioning this problem and tell about our use case, or create a new issue.
List of tasks that would need addressing:
Doing some brief testing with v3, I've noticed the following:
<script src="..."></script>
tags will not work. require
is also not available. The only solution would appear to be compiling all scripts into a single service worker file.Message listeners such as chrome.runtime.onMessage
should be set up immediately in the service worker in order to ensure that the messages are not dropped. For example:
// This must be done before any async calls occur.
chrome.runtime.onMessage.addListener((message, sender, callback) => {
// Handle
});
// Rather than something like this, which can result in
// dropped packets if the service worker was previously stopped.
(async () => {
await Promise.resolve();
chrome.runtime.onMessage.addListener((message, sender, callback) => {
// Handle
});
})();
chrome.commands.onCommand
chrome.tabs.onZoomChange
chrome.runtime.onMessage
chrome.runtime.onConnect
Branch for switching to declarative web request, eventually: https://github.com/toasted-nutbread/yomichan/commits/declarative-web-request
For some reason, this does not actually strip the Origin
header, so the jpod101-alternate
source doesn't work correctly. Unclear if this is a bug or if I'm not using the APIs/fetch correctly.
New branch for switching to declarativeNetRequest
, which replaces declarativeWebRequest
.
https://github.com/toasted-nutbread/yomichan/commits/declarative-net-request
This version does seem to work correctly, contrasted with the old declarativeWebRequest
.
As of now, despite the broken and sometimes non-existent documentation, MV3 is now supported with the build variant chrome-mv3
. The main feature that is currently not supported is clipboard observation from the background page, since there is no DOM to read the clipboard from in MV3. I opened an issue about this here: https://bugs.chromium.org/p/chromium/issues/detail?id=1160302
The Google Chrome team is working on a version 3 of the WebExtension manifest. While the timelines are still indeterminate at this point, it's better to start tracking and thinking about the changes this will entail sooner rather than later. We should use this issue to document any potential problems we may encounter.
Relevant links:
Noteworthy points:
This will present an issue with Handlebars.js, since it uses
Function
constructor to dynamically eval code.This is planned and in progress. Already started here: #447.
This is potentially the biggest change, and will affect at least a few things that I am aware of.
clipboardPasteTarget
shenanigans won't work. Not sure what the workaround for that would be.Related:
Originally mentioned in https://github.com/FooSoft/yomichan/issues/353#issuecomment-608961786, but this is worth its own issue.