One of my Manifest V3 addons is not waking up when it should

This is gonna be one of those hard to reproduce issues, I can feel it.

I have a super simple addon that moves tabs received from other device into own window.

I’m using it almost every day and today it didn’t do its job, so I went to see about:debugging page, and I see it’s not running:

Even though it has listener for browser.tabs.onCreated, it won’t start even when I open new tab or window.

So, something is wrong. But what, and how can I help?
I hate reporting bugs that can’t be reproduced and there is like 100% chance this is one of those :frowning:.
I’ve checked the browser console but I can’t find anything useful there.
Are there maybe some other logs I could check?

Is the extension consistently failing to start when a new tab opens in your browser right now? If not right now, at the time when you were observing it was it consistent? If so, we may be able to share some guidance about how to debug this issue using Firefox’s Browser Toolbox. Unfortunately, though, I don’t know enough about the implementation details of event dispatch to provide that guidance right now.

I haven’t restarted browser yet so yes, I can still reproduce it now. I open new tab and the extension doesn’t wake up. And I can’t make it wake up even if I want to since it doesn’t have popup :slight_smile:.

All other extensions work as expected.

I think I’ve experienced similar issue not long ago with one of my other addons on my other PC at work. It started after I migrated it from persistent to not-persistent background script (but still MV2).

In that case, the addon had a listener, which didn’t fired, even though the data in the store were changed. It happened only twice or so, so I didn’t investigated it further.

In any case, I’ve enabled and opened the Browser Toolbox and I can now inspect and debug everything, which is great, but indeed, without knowing where to put a debugger, it’s impossible to find the issue. Especially since there is no error in the console (after opening tabs) that would point me to the right direction… :frowning:

I’m trying to see if I can get/find/figure out any guidance on debugging this. I’ll try to follow up in less than 30 min.

If you can find someone skilled, I could even share a TeamViewer session and they could debug it on my machine.

To start, can you check the set of persistent listeners registered by your extensions? To do this, open Browser Toolbox and run the following snippet:


Also, could you please share the following information?

  • Firefox version number
  • Firefox channel (stable, nightly, etc.)
  • OS & version number
  • Whether you’re using the published version of the add-on or a local version

So, there are two listeners, as expected.
I’m running 128.b5, Developer Edition.
Using Windows 11 Pro 23H2.
The addon is normally installed from the store.

Thanks for that. I’m also seeing the same set of persistent listeners – I just installed the extension for testing/debugging purposes and ostensibly everything is working as expected right now.

I was testing it at work too and it worked normally, as always.
But this is what I see now:

1 Like

Very curious, indeed. Thanks for sharing a concrete video of the repro.

Could you run another snippet to get a more readable form of the listener data for us?

function convertNestedMap(m) { const res = {}; for (const [k, v] of m) { res[k] = typeof v?.has === "function" ? convertNestedMap(v) : v; } return res; }

JSON.stringify(convertNestedMap(WebExtensionPolicy.getByID("admin@fastaddons.com_SendTabToDeviceEnhancer").extension.persistentListeners), null, 2)
  "tabs": {
    "onCreated": {
      "[]": {
        "params": [],
        "nextPrimeId": 1,
        "listeners": [
            "primeId": 0
    "onUpdated": {
      "[null]": {
        "params": [
        "nextPrimeId": 1,
        "listeners": [
            "primeId": 0

Interesting. That’s different than what I’m seeing locally when my extension is awake or asleep. I’ve passed this data on to the relevant engineers.

Sorry for the legginess of this process and thank you for the help so far!

1 Like

No problem :slight_smile:, this is actually super exciting for me, even though it’s almost 11PM here :slight_smile:. I plan to stay up at least one more hour.

I just hope it will help find the root cause. In the big picture, it will for sure help me too since I’ll receive less bug reports from my users :slight_smile:.

1 Like

The engineer I was working with so far had to leave, but it sounds like we got some useful data. I’m going to read through some relevant Firefox source and see if there’s any other data that might be useful to collect.

1 Like

OK, great.
I’ll try to keep my Firefox running over the weekend and even next week so feel free to write me if you need to run more experiments!

1 Like

Something unrelated that I noticed:
In background_sttd.js, the listener gets registered inside the browser.tabs.onUpdated listener.
Doesn’t MV3 require that you register all listeners at the top level of the service worker?

Only if you want the listener to be able to wake up the worker. Otherwise it will work only until the worker is alive, which is more-less enough for the specific use case it handles :slight_smile:.

I’m going to keep poking around FF source for a bit longer, @juraj.masiar, but if you’re still up it’s probably best to call it a night. Thanks again for the help. I’ll be sure to follow up here as soon as I have an update over the next couple of days.

1 Like

OK, thanks for the help!
I’ll go sleep soon so good night and have a nice weekend :slight_smile:.

1 Like

Assuming the issue is still reproducing on your end, I have a pair of follow up questions for you, @juraj.masiar.

  1. Could you run the following snippet in Browser Toolbox and share the result? It should be a short string.
  1. Could you share the addonStartup.json.lz4 file from your profile directory with me? You can find the path to your profile directory by visiting about:profiles. I just sent you a message with my address.