-
Hi, I am looking for some best practices on handling extension installation and upgrade.
I found some guides on how to do this with the help of // background.js
chrome.runtime.onInstalled.addListener(async () => {
for (const cs of chrome.runtime.getManifest().content_scripts) {
for (const tab of await chrome.tabs.query({url: cs.matches})) {
if (tab.url.match(/(chrome|chrome-extension):\/\//gi)) {
continue;
}
chrome.scripting.executeScript({
files: cs.js,
target: {tabId: tab.id, allFrames: cs.all_frames},
injectImmediately: cs.run_at === 'document_start',
// world: cs.world, // uncomment if you use it in manifest.json in Chrome 111+
});
}
}
}); The above script works fine when user first install my extension. But I am not sure if it works fine when there is an upgrade on Chrome Web Store. (I am actually not sure how to test the "upgrade"). How do you handle Chrome WebStore "upgrade" for existing open tabs, so that old tabs receives upgraded Content Script UI in wxt with Shadow Root? One approach I can think of is just store a version number in local storage, and ask user to refresh the page when an old "content script" is used. Is there a better way to handle this without refresh the page manually? (I was using Plasmo and asked the same question on their github discussion and no one has replied, so I asked the same question here. I read through all the docs in wxt, and haven't found any related information on this.) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
It's there, see https://wxt.dev/entrypoints/content-scripts.html#context Maybe I should add a page to the guide about this instead of hiding it in the entrypoint docs. The As for testing upgrade behavior... You'll need to make 2 zips: one of an old release (or just an older commit) with a smaller version number, and the second with your new code and a newer version number. Before building the ZIPs, you'll need to add a So the steps:
To test more changes, you don't need to recreate the first ZIP, just restart the process from the step where you create the second zip. Wow, that was a lot of information, I'll add a dedicated page to the docs around testing update behavior.... |
Beta Was this translation helpful? Give feedback.
It's there, see https://wxt.dev/entrypoints/content-scripts.html#context
Maybe I should add a page to the guide about this instead of hiding it in the entrypoint docs.
The
ContentScriptContext
class is very simple, and I'd recommend you read through the source code to fully understand how it works.https://github.com/wxt-dev/wxt/blob/54e5ed0bb47964ddcbc8a5483f8b6ffe42704beb/src/client/content-scripts/content-script-context.ts
As for testing upgrade behavior... You'll need to make 2 zips: one of an old release (or just an older commit) with a smaller version number, and the second with your new code and a newer version number.
Before building the ZIPs, you'll need to add a
key
property to…