Persistent Service Worker in Chrome Extension
Service worker (SW) can't be persistent by definition and the browser must forcibly terminate all of SW connections such as network requests or runtime ports after a certain time, which in Chrome is 5 minutes. The inactivity timer when no such requests or ports are open is even shorter: 30 seconds.
Chromium team currently considers this behavior intentional and good, however this only applies to extensions that observe infrequent events, so they'll run just a few times a day thus reducing browser memory footprint between the runs e.g. webRequest/webNavigation events with urls
filter for a rarely visited site. These extensions can be reworked to maintain the state, example.
Such an idyll is unsustainable in many cases.
Problem 1: the worker doesn't wake up for webRequest events.
Although you can try to subscribe to an API like
chrome.webNavigation
as shown in the other answers, but it helps only with events that occur after the worker starts.Problem 2: the worker is randomly broken after an update.
The tentative workaround may be to add
self.oninstall = () => skipWaiting();
Problem 3: SW inactivity timer isn't prolonged for a new
chrome
API event in an already running background script. It means that when the event occurred in the last milliseconds of the 30-second inactivity timeout your code won't be able to run anything asynchronous reliably. It means that your extension will be perceived as unreliable by the user.Problem 4: worse performance than MV2 in case the extension maintains a socket connection or the state (variables) takes a long time to rebuild or you observe frequent events like these:
- chrome.tabs.onUpdated/onActivated,
- chrome.webNavigation if not scoped to a rare url,
- chrome.webRequest if not scoped to a rare url or type,
- chrome.runtime.onMessage/onConnect for messages from content script in all tabs.
Starting SW for a new event is essentially like opening a new tab. Creating the environment takes ~50ms, running the entire SW script may take 100ms (or even 1000ms depending on the amount of code), reading the state from storage and rebuilding/hydrating it may take 1ms (or 1000ms depending on the complexity of data). Even with an almost empty script it'd be at least 50ms, which is quite a huge overhead to call the event listener, which takes only 1ms.
SW may restart hundreds of times a day, because such events are generated in response to user actions that have natural gaps in them e.g. clicked a tab then wrote something, during which the SW is terminated and restarted again for a new event thus wearing down CPU, disk, battery, often introducing a frequent perceivable lag of the extension's reaction.
"Persistent" service worker while nativeMessaging
host is connected
In Chrome 105 and newer the service worker will run as long as it's connected to a nativeMessaging host via chrome.runtime.connectNative. If the host process is terminated due to a crash or user action, the port will be closed, and the SW will terminate as usual. You can guard against it by listening to port's onDisconnect event and call chrome.runtime.connectNative again.
"Persistent" service worker while a connectable tab is present
Downsides:
- The need for an open web page tab
- Broad host permissions (like
<all_urls>
or*://*/*
) for content scripts which puts most extensions into the slow review queue in the web store.
Warning! If you already connect ports, don't use this workaround, use another one for ports below.
Warning! Also implement the workaround for sendMessage (below) if you use sendMessage.
manifest.json, the relevant part:
"permissions": ["scripting"],
"host_permissions": ["<all_urls>"],
"background": {"service_worker": "bg.js"}background service worker bg.js:
let lifeline;
keepAlive();
chrome.runtime.onConnect.addListener(port => {
if (port.name === 'keepAlive') {
lifeline = port;
setTimeout(keepAliveForced, 295e3); // 5 minutes minus 5 seconds
port.onDisconnect.addListener(keepAliveForced);
}
});
function keepAliveForced() {
lifeline?.disconnect();
lifeline = null;
keepAlive();
}
async function keepAlive() {
if (lifeline) return;
for (const tab of await chrome.tabs.query({ url: '*://*/*' })) {
try {
await chrome.scripting.executeScript({
target: { tabId: tab.id },
function: () => chrome.runtime.connect({ name: 'keepAlive' }),
// `function` will become `func` in Chrome 93+
});
chrome.tabs.onUpdated.removeListener(retryOnTabUpdate);
return;
} catch (e) {}
}
chrome.tabs.onUpdated.addListener(retryOnTabUpdate);
}
async function retryOnTabUpdate(tabId, info, tab) {
if (info.url && /^(file|https?):/.test(info.url)) {
keepAlive();
}
}
If you also use sendMessage
In Chrome 99-101 you need to always call sendResponse() in your chrome.runtime.onMessage listener even if you don't need the response. This is a bug in MV3. Also, make sure you do it in less than 5 minutes time, otherwise call sendResponse immediately and send a new message back via chrome.tabs.sendMessage (to the tab) or chrome.runtime.sendMessage (to the popup) after the work is done.
If you already use ports e.g. chrome.runtime.connect
Warning! If you also connect more ports to the service worker you need to reconnect each one before its 5 minutes elapse e.g. in 295 seconds. This is crucial in Chrome versions before 104, which killed SW regardless of additional connected ports. In Chrome 104 and newer this bug is fixed but you'll still need to reconnect them, because their 5-minute lifetime hasn't changed, so the easiest solution is to reconnect the same way in all versions of Chrome: e.g. every 295 seconds.
background script example:
chrome.runtime.onConnect.addListener(port => {
if (port.name !== 'foo') return;
port.onMessage.addListener(onMessage);
port.onDisconnect.addListener(deleteTimer);
port._timer = setTimeout(forceReconnect, 250e3, port);
});
function onMessage(msg, port) {
console.log('received', msg, 'from', port.sender);
}
function forceReconnect(port) {
deleteTimer(port);
port.disconnect();
}
function deleteTimer(port) {
if (port._timer) {
clearTimeout(port._timer);
delete port._timer;
}
}client script example e.g. a content script:
let port;
function connect() {
port = chrome.runtime.connect({name: 'foo'});
port.onDisconnect.addListener(connect);
port.onMessage.addListener(msg => {
console.log('received', msg, 'from bg');
});
}
connect();
"Forever", via a dedicated tab, while the tab is open
Open a new tab with an extension page inside e.g. chrome.tabs.create({url: 'bg.html'})
.
It'll have the same abilities as the persistent background page of ManifestV2 but a) it's visible and b) not accessible via chrome.extension.getBackgroundPage
(which can be replaced with chrome.extension.getViews).
Downsides:
- consumes more memory,
- wastes space in the tab strip,
- distracts the user,
- when multiple extensions open such a tab, the downsides snowball and become a real PITA.
You can make it a little more bearable for your users by adding info/logs/charts/dashboard to the page and also add a beforeunload
listener to prevent the tab from being accidentally closed.
Caution regarding persistence
You still need to save/restore the state (variables) because there's no such thing as a persistent service worker and those workarounds have limits as described above, so the worker can terminate. You can maintain the state in a storage, example.
Note that you shouldn't make your worker persistent just to simplify state/variable management. Do it only to restore the performance worsened by restarting the worker in case your state is very expensive to rebuild or if you hook into frequent events listed in the beginning of this answer.
Future of ManifestV3
Let's hope Chromium will provide an API to control this behavior without the need to resort to such dirty hacks and pathetic workarounds. Meanwhile describe your use case in crbug.com/1152255 if it isn't already described there to help Chromium team become aware of the established fact that many extensions may need a persistent background script for an arbitrary duration of time and that at least one such extension may be installed by the majority of extension users.
How to make chrome extension active permanent
it is normal thing developing manifest version 3 extensions.
Chrome is becoming a browser that is everything but light and this is partly due to the dozens of extensions the user installs.
Thus Google introduced service worker in extensions in order to free up some memory whenever possible.
SW is activated when necessary and then goes to sleep until the moment it's awakened to perform a new job.
Said this,
- "persistent": true in manifest is useless and could generate an error.
- we have to realize that when SW becomes inactive all variables and objects defined in this script will be lost unless we plan to save them somehow in a persistent storage.
Normally, the asynchronous chrome.storage API are used to save variables \ objects used in the SW. - If you cannot allow SW become inactive (for some important reason) you could use a "dirty" technique that bypasses this "restriction".
This technique consists in opening a long-lasting communication channel and sending fictitious messages between SW and any browser tab.
For more details on this technique read this thread: Persistent Service Worker in Chrome Extension
Related Topics
How to Read an External Local Json File in JavaScript
How to Get the Coordinates of a Mouse Click on a Canvas Element
Detect the Internet Connection Is Offline
How to Output Numbers With Leading Zeros in JavaScript
Pad a Number With Leading Zeros in JavaScript
Creating Object With Dynamic Keys
Surprised That Global Variable Has Undefined Value in JavaScript
How to Pass Variable into an Evaluate Function
Console.Log() Shows the Changed Value of a Variable Before the Value Actually Changes
No Visible Cause For "Unexpected Token Illegal"
Take a Screenshot of a Webpage With JavaScript
Why Does .Json() Return a Promise
Group Array of Object Nesting Some of the Keys With Specific Names
Use of .Apply() With 'New' Operator. Is This Possible
How to Convert a Comma-Separated String to an Array