Service worker not waking up...

[Juraj M.]

From time to time I get a report from user that shows that the background script is not responding to a simple "ping" message.

I remember this was "solved" already here:
https://issues.chromium.org/issues/40805401

But I have a feeling there are still some cases when this happens.

For example NOW, on my own PC :).

I'm running  Version 146.0.7668.2

And the "chrome://serviceworker-internals/" shows this:

ServiceWorker

Registrations in: C:\Users\juraj\AppData\Local\Temp\tmp-web-ext--28332-nkE8fqedV4vi\Default (2)

Scope: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc/

Storage key:

Origin: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc

Top level site: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc

Ancestor chain bit: SameSite

Registration ID: 2

Navigation preload enabled: false

Navigation preload header length: 4

Active worker:

Installation Status: ACTIVATED

Running Status: STOPPED

Fetch handler existence: DOES_NOT_EXIST

Fetch handler type: NO_HANDLER

Script: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc/background.loader.js

Version ID: 2

Renderer process ID: 0

Renderer thread ID: -1

DevTools agent route ID: -2

Client:

ID: 261976bf-9aa3-4c45-a732-f8cc4f8a54fc

URL: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc/dial.html

Client:

ID: 897e5692-1063-4f25-b452-a4172ebf0653

URL: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc/dial.html?reload

Client:

ID: 8c0b235a-aba8-4b8f-9af2-41a7afd29384

URL: chrome-extension://ipljpmoncjninbaffhpemfdkaipaabkc/dial.html#47

I'm not sure when it broke, I've just noticed my extension is somewhat broken and then I've noticed it's due to inactive service worker.

Even if I click the "service worker (inactive)" link in the chrome extensions page, nothing happens.

Are there maybe some logs I could check right now to help investigate this?

[Oliver Dunk]

Hi Juraj,

Unfortunately, these issues are quite tricky to troubleshoot and generally there isn't enough information on the chrome://serviceworker-internals page to determine the issue.

If you are able to reproduce with more verbose logging enabled, you can sometimes see the service worker failing to register with a reason in the logs: https://www.chromium.org/for-testers/enable-logging/. However, that isn't helpful retroactively of course.

Do keep an eye on this and let us know if you continue to see reports. It's helpful to hear how often it is happening.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1fc56d40-489d-41a8-a239-3effadb7ac62n%40chromium.org.

[woxxom]

Chromium should add a check for a missing SW registration in a messaging attempt as that could happen due to a file system corruption caused by a crash or a bug or a bad sector. In such cases the browser could try re-registering the SW automatically (while still being in a messaging cycle) without issuing events to the SW like chrome.runtime.onInstalled or self.oninstalled etc.

Also, given the historical fragility of the implementation that already required multiple patches over the recent years, there's still possibly many undiscovered bugs that can't be easily reproduced even by the reporters, so it would make sense for chromium to discover them proactively by incorporating more logging for extension-SW at least in the Canary browser channel or maybe add relevant dedicated scenarios to the test build fuzzer.

Juraj M., try adding self.onfetch = () => {} which would make your sw look more like a normal one to the browser.

[Andrea Orru]

Hi Juraj, woxxom,

I'm working in this area (service workers reliability).

> I remember this was "solved" already here: https://issues.chromium.org/issues/40805401

If I recall correctly, that bug was specifically about service workers occasionally breaking after updates. The thread got sidetracked a few times, but I believe the main root cause of that bug has been solved.

Regarding the case that you are reporting now, did the service worker stop working as a result of an update?

Could you provide more details about the extension? Which events is it listening to?
Also, could you provide the content of chrome://extensions-internals while the service worker is in the broken state?

> In such cases the browser could try re-registering the SW automatically [...] there's still possibly many undiscovered bugs that can't be easily reproduced even by the reporters, [...]

That is a good suggestion, but as of Chrome M142, we already retry on both registration and start failures.

I believe we have made a lot of progress in recent milestones, but there can still be subtle race conditions, some of which are known (and I'm currently working on).

Best,

Andrea

[Juraj M.]

Hello Andrea,

If I remember correctly, I've started the instance, imported some data into my extension, and manually reloaded the extension - although I can't tell whether I've used the Chrome button or my own button in the extension that calls the runtime.reload().

This can be confirmed by the profile folder files age, which says it was created at "‏‎15:28:46" and first runtime log from my extension is at "15:30:04", so it was reloaded shortly after start.

I'm using web-ext tool for development and this broken instance got started without automatic reload capability:

web-ext run --no-reload -t chromium --chromium-profile C:\tmp\chrome_dev_profile

My extension (Group Speed Dial) has a huge codebase, so it listens to a lot of events, I think the "chrome://extensions-internals/" page lists them all, right?
See the attached text file for the page contents.

Since broken background script was historically always a problem (also in Firefox some years ago), I've rebuilt my extension in way it can somewhat function even without the background script.

So I'm not getting a lot of reports anymore, because people don't see it's broken, unless they try to use a feature that needs the background script.

And when they send me runtime logs, it always contains a "ping check" that tests whether the background script can reply, that's how I know it's still happening.

I still have the broken Chrome instance running, I'll restart my PC only when OS needs restarting, which will happen upcoming Wednesday due to Windows update :). So I can run some experiments on it until then.

[Juraj M.]

One more interesting note, here are my app internal runtime logs, on the left the broken one, on the right the expected log right after reloading extension:

(I'm storing runtime logs in the browser.storage.session storage, so they are accessible even when background script is broken)

As you can see, there are two logs missing on the left:
1. System: onInstalled: update 29.4 - this one is logged from:

browser.runtime.onInstalled.addListener(async ({reason, previousVersion}) => {
  iLog(`onInstalled: ${reason} ${previousVersion}`);

2. System: First tab starts loading - this one is logged when the extension page (dials page) loads in a new tab and asks background script whether it's OK.

At the same time, the "System: store ready" was logged, so the main background script code was executed without errors.

To summarize - background script was executed, but the "onInstalled" event did not fire, nor the "onMessage" moments later.

[Andrea Orru]

Thanks for all the context Juraj. That is extremely helpful.

I have a few suspicions; I'm going to spend some time trying to reproduce this tomorrow.

Best,

Andrea