Strange MV3 behaviour - browser.runtime.onInstalled event and menus.create

Add-ons Development
#1

When you place menu creation in a runtime.onInstalled listener using menus.create , as recommended by the docs, it works as expected initially.

However, if you disable and re-enable the extension, the item disappears from the context menu.

Here is the sample code:

browser.runtime.onInstalled.addListener(() => {
  browser.menus.create({
    id: "someId",
    title: "Some title",
    contexts: ["image"],
  });
});

Is this an MV3 issue? If so, is there a way to bypass it?

Thank you!

1 Like
#2

I think Chrome had this problem as well in the earlier versions.
It’s best to report it to bugzillla and hope for quick fix :slight_smile:.

As a quick workaround you could re-register menus “onStartup”:


(so, create “reCreateMenus” function that clears existing menus and then creates them and then run it on install and on startup)
#3

Ah, I thought so. Thanks for your reply!

I opened a ticket with bugzilla. Hopefully, this gets resolved asap as this is causing issues for a lot of our users.

I’ve tried re-registering with runtime.onStartup but unfortunately, that doesn’t re-generate the menu item.

The only way the menu item is re-generated is if you do not place menus.create inside any listener. But that causes other issues.

1 Like
#4

The “onStartup” should run only once when Firefox starts, so it should help “eventually”, unless it’s also somehow broken. With these “less popular” API one never knows :frowning:.

Alternatively, you could create an Alarm that would re-create it every few hours - again terrible workaround. Although, I have a feeling this would not work as expected either…

1 Like
#5

Unless this is resolved soon, I think we may just have to revert back to our MV2 extension until MV3 and non-persistent scripts are more stable. Especially since FF will continue to support MV2 for the next little while.

Anyway, thank you for your input! I appreciate it!

#6

No problem :slight_smile:.

Downgrade is pretty good plan!
And Firefox ESR users will be happy as well since they can’t run MV3 addons yet.

1 Like
#7

Enabling and disabling the add-on does not trigger the installed event listener. This is not specific to MV3 and it’s the expected behavior.

You shouldn’t have your menu creation code in the installed listener because it will only fire when you first install or the add-on is updated. Even if you restart the browser you will have the same issue of the menus not being added.

#8

Maybe a dupe of 1771328 - Restarting manifest v3 extension removes its context menu entry

2 Likes
#9

That’s true, but menus in MV3 should be persistent across “disable/enable” states, just like storage.
And it’s indeed recommended by the docs:

Listen to the runtime.onInstalled event to initialize an extension on installation. Use this event to set a state or for one-time initialization, such as a context menu.

1 Like
#10

For now, this can be worked around by always creating the menu at the top level of the background script.

bug 1771328 comment 1

2 Likes
#11

Creating the menu at the top level of the background script works until the browser receives an update. After which, the extension needs to be disabled and re-enabled.

#12

You mean when addon is updated by the browser?

But if the menu creation is on the top level of the background script, and background script is re-executed every time the addon is woken up (including when update is installed), then the menu should always be re-registered.

1 Like
#13

No, when a browser receives an update. E.g., going from Firefox v109 to v110.

#14

Would reloading the extension trigger the menu creation code?

function runtime_on_installed(details) {
	if (details.reason == "browser_update") {
		browser.runtime.reload();
	}
}

browser.runtime.onInstalled.addListener(runtime_on_installed);
#15

It’s possible but difficult to test since when you close the browser with a temp add-on, the add-on is going to be uninstalled. I think it’s best to stick to MV2 until MV3 is more stable.