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 .
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…
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!
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.
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.
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.
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.
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.