Intermittent issues with service worker becoming inactive

[Gaurang Tandon]

Hi! As we're rolling out our MV3 extension, we're hearing intermittent issues where the extension becomes unresponsive for some users. All of them have the extension service worker inactive. Clicking on its link in chrome://extensions "Inspect views" doesn't open its console window. It remains inactive even when the user is actively switching browser tabs. This is unexpected because our service worker has a top-level tabs.onActivated listener. The users are on the latest Chrome 126.

When this issue happens, the "chrome-extension://<ID>/manifest.json" doesn't load, and it gives a page unresponsive popup after waiting for a few minutes. Also, sometimes the offscreen document is missing from the "Inspect views" list. Other times, it's there but its "Elements" panel is empty. But, mostly its console doesn't open on clicking.

The only way to fix this issue is to re-enable the extension, re-install the extension, or restart the browser. It's difficult to debug this issue because the extension context console is inaccessible.

I'm curious if other devs are seeing similar issues and if so are there any techniques to handle these issues more gracefully/automatically? Also curious if the Chrome team is aware of similar bugs and working to address them? Thanks!

[Peter Bloomfield]

I'm not sure if this will be helpful, but I've recently seen something similar when our extension tries to save too much data to local storage in a single contiguous block (e.g. a huge array). I suspect it's hitting an internal memory limit, resulting in a hard crash of the extension service worker. It can be manually reproduced by running this command in the service worker console:

await chrome.storage.local.set({ test: Array(35000000).fill(0) });

I'm not certain if the limit is the same across all devices so your results may vary.

The solution for us was basically to split the data up into multiple smaller arrays. We also added various safeguards and explicit limits in our own code to avoid accumulating so much data in the first place where possible.

As a side note, the problem seems to be much more common since upgrading to manifest v3, even though 99% of our code is identical. Whatever limit we're hitting seems to have been higher for manifest v2 extensions.

[Gaurang Tandon]

Hi Peter, thanks for your response. I agree that's an issue, although the issue I'm seeing seems different.

To summarise, on Chrome 126, our extension service worker becomes inactive - for unknown reason - and then remains inactive even when the extension is enabled/disabled. Uninstalling and reinstalling the extension fixes the issue.
So far, this issue has happened 1. without the extension auto updating, and 2. independently of how much data is written to storage (which is less than a few megabytes for us), and 3. on both macOS and Windows.

I'm happy to provide more useful info so the team can debug this, but I would need more guidance on the same from the community or the team. Thanks!

[Zoltan Szalontai]

We have this issue ever since we started using MV3 extensions (like a year). The service worker becomes inactive randomly and we need to restart chrome or reinstall the extension to get it running again. This happens most often on cheap Windows laptops so my best guess is that Chrome stops extensions to save resources but there doesn't seem to be a way to troubleshoot it. I didn't find any logs or notifications indicating why did it get stopped.

[hrg...@gmail.com]

This happens most often on cheap Windows laptops

Those are the most abundant kind of computers, so it's expected that any bug will manifest more frequently in those.

I still obverse the problem sporadically on my machine which has plethora of RAM. Sometimes I see 2 service workers in the extension's details page; that's an immediate indication that the service worker won't respond to any new messages or events.

I've never been able to reproduce it, it happens seemingly at random.

[Gaurang Tandon]

Hi Zoltan and hrg, thanks for confirming that you have also seen the issue. We have seen the issue with not cheap laptops and macbooks as well. If the SW was shutdown to save resources, I agree with you that that should be clearly indicated. I also feel that afterwards the service worker should be restarted when the user tries to interact with the extension. 

I should also note that this issue is especially frustrating for users with extensions installed by forced enterprise-policy. Once they get this issue, they cannot reinstall the extension on their own. The only way for them is to then close everything that they were doing and restart their laptop.