Manifest V3: service worker not registered in popular extension

[Pawel Kacprzak]

Three weeks ago I pushed an update to my extension that moved from MV2 to MV3 and added some features. The extension has 50k users with ~600k uses per week and is featured in the store so I was super careful with the update knowing the current reputation of MV3. 

The launch was successful; I tested the extension heavily before the update, and had it on a 10% rollout, to begin with, no one complained, so increased the rollout to 100% after a week with a public launch of the new features - no complaints.

However, over time, I started receiving emails from users that the extension refuses to open - it's supposed to open when you click the icon and it inserts some UI to the current tab, in other words, it adds a listener to `chrome.action.onClicked`. 

Yesterday, I experienced it myself and today it happened again - nothing happens when I click the extension icon. So I used all I know to debug it but unfortunately without any success so far. Here's what I tried:

1. In `chrome://extensions/` the service worker is inactive, which is normal and it was waking up properly in reaction to events

2. I tried the service worker debugging technique and to my surprise, no service worker is showing in Application->Service Workers. I confirmed that by inspecting all service workers registered in the browser

Is there any way of digging into it to find the root cause of this issue? Or is this maybe a bug in Chrome? And if it's a bug then is there any way of fixing/preventing it from happening?

Thanks,

Pawel

[Uladzimir Yankovich]

Welcome to V3 :( 

[wOxxOm]

There's a bug with action.onClicked: see https://crbug.com/1316588, it lists some workarounds + try switching to default_popup in manifest.json instead of onClicked.

[Pawel Kacprzak]

@wOxxOm it may be somehow related to that but the below pieces of evidence make me feel this is something different:

1. My extension has other listeners that should awake the worker, e.g. `chrome.tabs.onUpdated`, `chrome.tabs.onRemoved`, `chrome.runtime.onMessageExternal`, but none of them wake up the worker

2. The worker is not registered, i.e. not shown in `chrome://serviceworker-internals/?devtools` and not shown in `chrome-extension://xxx/manifest.json` Console->Application->Service Workers so if it's unregistered my understanding is that it won't react to events unless it's registered again, is that correct?

Meanwhile, I restarted the extension by turning it off and on in `chrome://extensions` and the worker was registered successfully and it's working so far (until it stops working again for some reason).

[wOxxOm]

In that case it's the worst bug to date that has been hitting users randomly for the past year or so and Chromium team can't reproduce it. The workaround may be to use `default_popup` and when it opens you can check if SW is registered:

navigator.serviceWorker.getRegistration().then(r => {
  if (r) return;
  const bg = chrome.runtime.getManifest().background;
  navigator.serviceWorker.register(bg.service_worker, {
    type: bg.type || 'classic',
    scope: '/',
  });
});

[Pawel Kacprzak]

That's so unfortunate - thanks @wOxxOm for the suggested workaround but I'm wondering if there is any way of using the `default_popup` and a `chrome.action.onClicked` listener simultaneously, or maybe a workaround to do what you suggest outside of the popup? The UI I'm injecting is far too complex to be a popup.

[wOxxOm]

It can't be used simultaneously.

The workaround may be to close the popup after injecting the UI in the tab by using `window.close()` - maybe it'll be so fast that the popup won't be even shown.

Another workaround is to disable the popup programmatically in the existing tabs so that when the service worker gets unregistered due to the bug, the user is likely to open a new tab at some point where your popup will be working and it will re-register the SW.

chrome.tabs.onCreated.addListener(tab => {
  chrome.action.setPopup({popup: '', tabId: tab.id});
});

You can even show a message in the popup about this being a bug in Chrome that should have completely stopped all ManifestV3 promotion but instead it's not acknowledged officially. 

[Pawel Kacprzak]

Closing the popup is an awesome idea, I think I understand what workflow you have in mind and implemented it like that:

popup.js (inserted into popup.html via <script> tag and `default_popup` set to popup.html in manifest)

const open = () => {
  chrome.tabs.query({
    active: true,
    currentWindow: true
  }, ([currentTab]) => {
    chrome.runtime.sendMessage({ action: 'open', tab: currentTab }, () => {
      window.close();
    });
  });
}
navigator.serviceWorker.getRegistration().then(r => {
  if (r) {
    open();
  } else {

    const bg = chrome.runtime.getManifest().background;
    navigator.serviceWorker.register(bg.service_worker, {

      type: 'classic',
      scope: '/',
    }).then(() => {
      open();
    });
  }
});

Then in the service worker:

1. I removed the action.onClicked listener 

2. the worker handles the open message sent from the popup by injecting the UI into the tab and calling sendResponse() to reply to the message, it looks like that:

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.action === "open") {
      handleOnOpenClick(request.tab);
      sendResponse();

    }

    return true;

  }

);

This seems to work fine. If the worker is already registered, the popup is closed so fast that it's probably invisible. Otherwise, the popup is visible for around the time it takes to register the worker which is very short and acceptable. 

Is this what you had in mind? 

Would inserting the UI like that be as reliable as a listener to action.onClicked?

[Simeon Vincent]

In that case it's the worst bug to date that has been hitting users randomly for the past year or so and Chromium team can't reproduce it.

I fear wOxxOm is right. The relevant issue is crbug.com/1271154. We closed this in part because it wasn't clear whether the issue was still occurring in the latest releases. In comment 68 I included some notes on what information might help us investigate the problem.

3. Add a comment to the relevant bug and include the following information.

  * The extension's manifest version.

  * The type of background context used (persistent page, event page, or service worker).

  * The version listed on chrome://version (e.g. 104.0.5112.101).

  * The name of your operating system.

  * The version number of your operating system.

  * A description of what happened before the extension stopped responding to events.

  * Any additional information that you believe might help identify the underlying issue.

  * (optional) A redacted copy of the relevant extension object from the chrome://extensions-internals page.

  * (optional) For those comfortable debugging Chromium, enable additional logging by following the guidance that appears after "I've uploaded a CL [1] with a smattering of various logs" in this comment: https://crbug.com/1316588#c68

Simeon - @dotproto

Chrome Extensions DevRel

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOpTrTD5nF34cxwFC8QJwkbHGEjpb0iRpO1GhJniomrvT5xMjw%40mail.gmail.com.

[Browser Extenstion]

Nobody from google team is working on bug https://crbug.com/1337294 that is related to the problem described in this question:

My extension has other listeners that should awake the worker, e.g. `chrome.tabs.onUpdated`, `chrome.tabs.onRemoved`, `chrome.runtime.onMessageExternal`, but none of them wake up the worker

All information with code examples are provided, but google prefers to just ignore the problem.

[Pawel Kacprzak]

Nobody from google team is working on bug https://crbug.com/1337294 that is related to the problem described in this question

It may be related but in my case, the worker is working properly when registered, i.e. it wakes up from inactive on all expected events. The problem is that the worker gets unregistered and not after an update or manual refresh, just "randomly" and not often. 

Yesterday I sent a mass email to our users explaining the situation and providing a temporary workaround (disabling and enabling the extension which re-resters the worker). I was actually surprised by the response because many users affected by this figured out this workaround by themselves and reported that it happened 1-2 times in a span of 2 weeks of daily use.

I'm now considering the following options:

1) leave it as it is and wait for more information that may help find the real cause of the issue and maybe a fix

2) use the workaround based on @wOxxOm answer I shared here: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/MesMv9ugQIQ/m/Hk4D8LILBAAJ which seems to work but opening a popup, sending a message from it, and closing the popup is not as clean as adding a listener to chrome.action.onClicked

@wOxxOm would you mind taking a look at my implementation of your popup idea and giving your opinion on it? https://groups.google.com/a/chromium.org/g/chromium-extensions/c/MesMv9ugQIQ/m/Hk4D8LILBAAJ

[wOxxOm]

>  would you mind taking a look at my implementation

Seems fine. Maybe try the second idea I suggested (disabling the popup in existing tabs).

[Pawel Kacprzak]

Do I understand correctly that with the idea of disabling the popup in existing tabs I'd need the additional listener for action.onClicked to handle the icon click events where the popup is disabled?

[wOxxOm]

Yep, it should work there.

[Pawel Kacprzak]

Ok, so disabling the popup seems to have both pros and cons

pros: when there is no bug, i.e. worker is not unregistered, users don't see the popup which is better than opening and closing the popup with every single use, both from UI and general design perspective

cons: when the worker gets unregistered after the popup is disabled then there is no way of using the extension in the current tab, while without disabling the popup it should work just fine in that situation

Makes sense? 

[Pawel Kacprzak]

@wOxxOm any opinion on this?

[wOxxOm]

My opinion is this is a bad bug that should stop all promotion of ManifestV3 until fixed.

[Pawel Kacprzak]

I agree. But there's also reality and in this case, the reality is that the bug occurs in a production version of an MV3 extension and I'm trying my best to push a workaround/fix. I asked because I value all your inputs that helped me a lot with this (unfortunate) MV2 to MV3 transition so far. Maybe I could've waited a bit longer with the transition but my reasoning was: 1) there's little hope MV3 gets fixed before the scheduled timelines 2) I'd rather give myself time to do the transition right and iterate on possible bugs than rush with the transition at the latest possible time.

[Guy S]

We have the same exact issue. Did you guys implement some workaround?