Context menus onInstalled clarification

[Ottis]

Hi, please could someone let me know if the following is correct, in the context of MV3 extensions:

1. Chrome extensions only need to create context menus on the onInstalled event. This is because once created, the context menus are automatically restored by the browser if the browser is exited and restarted. Therefore, if the onStartup event fires, at that point, previously created context menus are guaranteed to be automatically restored.

2. If the onInstalled event is fired, it is guaranteed that there are no existing context menus that need to be removed before creating new ones (assuming the code does not create context menus outside of the onInstalled event handler)

3. The guarantee in item 2 above applies no matter what the cause of the onInstalled event is (extension first installed, extension is updated to a new version, Chrome is updated to a new version)

4. If the onInstalled event fires, this guarantees that the onStartup event will not also fire, and vice-versa (if onStartup fires, onInstalled won't fire).

Thanks!

[Jackie Han]

1. Yes

2. No

3. install and update is guaranteed, "chrome_update" is not guaranteed

4. No. onInstalled and onStartup are both fired when the browser is upgraded to a new version.

If your context menu is static in a specific version of your extension, the safest approach is to:

chrome.runtime.onInstalled.addListener(function() {

    chrome.contextMenus.removeAll(function() {

        // create all context menus

    });

}); 

See also:

1. I have summarized persistent states: https://github.com/w3c/webextensions/blob/main/memo/persistence-of-states.md

2. remove before creating: https://github.com/w3c/webextensions/issues/312

--
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/a422ae22-b938-4b62-b8f0-f9eb5dba1665n%40chromium.org.

[Ottis]

Thank you, this is incredibly useful information!

One other thing: are you aware of a race condition or bug that can occur in Chrome where an extension can have more than one top-level context menu appear (for the same extension)?

This should not be allowed by Chrome, but I've had some people report this happening. I think it may be due to my code removing and restoring all context menus, whether there is an onStartup or onInstalled event.  I'm thinking the bug could be triggered by 1) Both onInstalled and onStartup events firing if the browser is updated to a new version or 2) Because context menus are removed and restored on onStartup, and there is a race condition between Chrome automatically restoring existing menus and my code recreating the menus.

[Jackie Han]

"more than one top-level context menu" should be a bug in Chrome as your own explanation. I only use the onInstall event and have not encountered this problem.

[Ottis]

Great - thanks again for your help

[Max Nikulin]

On 04/06/2024 00:29, Jackie Han wrote:
> 1. I have summarized persistent states:
> https://github.com/w3c/webextensions/blob/main/memo/persistence-of-states.md

Am I wrong that in the case of Firefox add-on with *persistent*
background page, context menu items should be created when background
page is loaded (outside of any event listeners) so there is no
persistence across sessions?

I have the following link in my notes:
https://stackoverflow.com/questions/33834785/chrome-extension-context-menu-not-working-after-update

Is some workaround still required for the case that runtime.onInstalled
is not fired?

[Jackie Han]

For persistent background page ("persistent": true), it behaves differently.

I did some simple tests by disable-then-enable the extension:

- MV2, Chrome, persistent: true : context menu is not persistent

- MV2, Chrome, persistent: false : context menu is persistent

- MV2, Firefox, persistent: true :  context menu is not persistent

- MV2, Firefox, persistent: false :  context menu is not persistent

I am not very familiar with firefox. Only persistent pages are supported before Firefox 106. Please continue to use your existing way.

https://stackoverflow.com/questions/33834785/chrome-extension-context-menu-not-working-after-update
Is some workaround still required for the case that runtime.onInstalled is not fired?

https://crbug.com/388231: Looks like there is no such problem now.

https://crbug.com/264963: I am not sure.

--
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/03ebda1c-65c5-461c-ba4c-fceb170cbdd5%40gmail.com.

[Max Nikulin]

On 05/06/2024 14:40, Jackie Han wrote:
>
> For persistent background page ("persistent": true), it behaves differently.
> I did some simple tests by disable-then-enable the extension:

> - MV2, Firefox, persistent: true :  context menu is not persistent
> - MV2, Firefox, persistent: false :  context menu is not persistent

This is consistent with my experience. So "B+D" in the table is not
always true. In the past I was surprised when menu available immediately
after add-on install disappeared in later browser sessions.

> https://stackoverflow.com/questions/33834785/chrome-extension-context-menu-not-working-after-update
> Is some workaround still required for the case that
> runtime.onInstalled is not fired?
>

> https://crbug.com/388231 <https://crbug.com/388231>: Looks like there is
> no such problem now.
> https://crbug.com/264963 <https://crbug.com/264963>: I am not sure.

Thanks. Since nobody on this list confirmed the issue it should be safe
to assume that no workaround is necessary.

[Ottis]

To clarify: I assume these issues are only MV2-related?

If we only set up context menus in response to the onInstalled event in a Firefox MV3 non-persistent background page, will the context menus always be automatically restored when Firefox restarts?

[Jackie Han]

For Firefox, it is a complex issue.

First, read this article https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/ , the "Event-driven background scripts" section. The article describes a lot of the initialization of the context menu.

Second, read this https://extensionworkshop.com/documentation/develop/testing-persistent-and-restart-features/ (Testing persistent and restart features in Firefox).

I did some tests again. In my understanding, conclusions are:

- Firefox MV3, event page ("persistent": false): context menus persist across Firefox restarts, but don't persist across disable-then-enable.

- Firefox MV2, non-persistent background ("persistent": false) (Firefox >= 106): context menus persist across Firefox restarts, but don't persist across disable-then-enable.

- Firefox MV2, persistent background ("persistent": true): context menus do not persist across Firefox restarts, and don't persist across disable-then-enable.

In other words, 

1. no matter MV2 or MV3, event page or persistent background, Firefox context menus don't persist across disable-then-enable. 

2. Firefox >= 106, MV2 + "persistent": false or MV3 event page, Firefox context menus persist across Firefox restarts.

3. Firefox MV2 + "persistent": true, Firefox context menus don't persist across Firefox restarts.

--
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/ad89c779-44c6-457e-8425-b23cfb235f12n%40chromium.org.

[Ottis]

Thanks Jackie, your explanation is very much appreciated.

I think my strategy will be to require FF 106+. Then, assuming that the onStartup event is still fired when an extension is enabled (after being disabled), I'll write code to try and update a menu that should exist. If I get an error thrown (due to the menu not having been automatically restored), I'll know to re-create the context menus.

[Jackie Han]

This is consistent with my experience. So "B+D" in the table is not always true.

I updated the row of contextMenus at https://github.com/w3c/webextensions/blob/main/memo/persistence-of-states.md

assuming that the onStartup event is still fired when an extension is enabled (after being disabled)

the onStartup event is not fired when an extension is enabled in any browsers. Currently, there is no "onEnable" event, it will be fixed in the future https://github.com/w3c/webextensions/issues/353 . To workaround this in Firefox, try to create menus every time the background page starts.

[Max Nikulin]

On 06/06/2024 17:18, Jackie Han wrote:
>
> I updated the row of contextMenus at
> https://github.com/w3c/webextensions/blob/main/memo/persistence-of-states.md

Thanks.

It seems persistence of context menu created from onInstalled listener
across browser or extension restarts has been fixed recently:
https://bugzilla.mozilla.org/1771328
It means that a workaround for the case of event pages is still necessary.

A couple of related bugs are still open:
- <https://bugzilla.mozilla.org/show_bug.cgi?id=1817287>
"browser.runtime.onInstalled event not fired when disabled add-on is
re-enabled, and menus.create registration disappeared"
- <https://bugzilla.mozilla.org/show_bug.cgi?id=1700797>
"runtime.onInstalled Does not run if the extension is updated while
it is disabled"