Context menu appears on the pages of other extensions. It's a normal behaviour?

[Robbi]

The extension below, creates a context menu on all pages.
It appears on the pages of other extensions and also in chrome://extensions/
I then realized that I forgot to set the property: "documentUrlPatterns"
Q: Is it normal that it also appears on the pages of other extensions?

/* manifest.json */

{
"manifest_version": 3,
"name": "bug menù",
"short_name": "bm",
"description": "bla bla bla",
"version": "1.0",
"background": { "service_worker": "main.js" },
"permissions": ["contextMenus"]
}

/*-----------------------------------------------------------------------------------*/

/* main.js */

chrome.runtime.onInstalled.addListener(d => chrome.contextMenus.removeAll(predisponiMenu));

chrome.contextMenus.onClicked.addListener((info, tab) => console.log(info.menuItemId));

function predisponiMenu() {
function createSons(par, sons) {
for (let k = 0; k < sons.length; k++) {
son = sons[k];
chrome.contextMenus.create({
"id": son.id,
"title": son.title,
"enabled": son.enabled ?? true,
"parentId": par,
"contexts": son.contexts || ["page"]
});
if (son.children)
createSons(son.id, son.children)
}
}

const contextMenuItem = [{
"id": "annulla",
"title": "Annulla",
"contexts": ["page"],
"enabled": true,
"children": [{
"id": "ultimaSelez",
"title": "Ultima selezione"
}, {
"id": "tutto",
"title": "Tutte le ultime selezioni non marcate"
}, {
"id": "fromScratch",
"title": "Ricomincia da capo"
}]
}];

var cmi;
for (let k = 0; k < contextMenuItem.length; k++) {
cmi = contextMenuItem[k];
chrome.contextMenus.create({
"id": cmi.id,
"title": cmi.title,
"enabled": cmi.enabled ?? true,
"contexts": cmi.contexts
});
if (cmi.children)
createSons(cmi.id, cmi.children)
}
}

[Simeon Vincent]

This feels like it both is and is not working as expected. 

It feels like it is NOT working as expected because extensions aren't generally able to directly interact with other extensions. For example, Extension A cannot inject a content script on pages loaded on Extension B's origin. Preventing extensions from injecting content into and modifying other extensions limits the danger of malicious extensions performing privilege escalation attacks or otherwise violating end user expectations. 

It feels like it IS working as expected because context menus do not grant direct access to content on another extension's page. Instead, it exposes a limited view of where the command was invoked which includes data like the menu item selected, the URL of the tab where it was clicked, a string of text that the user had selected, etc. This data is still relevant and useful even on another extension's page. For example, this could be used to save a snippet of text into a quote catalogue or manage the layout of browser windows.

After thinking out loud for a moment, I'm inclined to say that this is working as expected.

Simeon - @dotproto

incremental.software

--
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/97d9ae97-2a5c-45ae-8ad7-b6f604473bfcn%40chromium.org.

[Robbi]

Ok, so I can read the tab url, but i cannot access that page unless I add "activeTab" permission to the manifest file.

Did I get it right?

Thanks

[Simeon Vincent]

That depends on what you mean by "access the page." If you mean interacting with a Tab object that contains another extension's page, yes. If you mean injecting a content script into another extension's page, then no. Extensions cannot inject content scripts into other extension pages.

I'm not exactly sure what you're trying to accomplish, but it's probably best to restrict your context menu's documentUrlPatterns value to match *://*/*. Using an asterisk for the scheme will only match against HTTP and HTTPS pages.

Simeon - @dotproto

incremental.software

[Robbi]

>  I'm not exactly sure what you're trying to accomplish <

nothing in particular; I was just setting up a menu that should only appear only on a page of the extension.

I guess then I'll have to restrict "documentUrlPatterns" to something like chrome.runtime.getURL('myPage.html').

To be honest, I don't know yet if I will adopt this type of menu  because I would like to limit the menu scope only to the cells of a html table.

For this I opened another thread asking for an opinion on a possible feature request. (thread link)

[Max Nikulin]

On 07/07/2023 03:47, Robbi wrote:
> Ok, so I can read the tab url, but i cannot access that page unless I
> add "activeTab" permission to the manifest file.

> On Thu, Jul 6, 2023 at 6:03 AM Robbi wrote:
>
> The extension below, creates a context menu on all pages.
> It appears on the pages of other extensions and also in
> chrome://extensions/

From another post I see you are trying to limit context menu to your
own extension, so the following may be unrelated.

Be prepared to get "tab.id: -1" in an event listener (or even undefined
instead of Tab in other browsers) and no access to the top level page of
the browser tab as it may be perceived by users despite the activeTab
permission. For example, PDF files have their own internal tab (I guess,
as content of <object> elements). Extension options is a similar beast
when opened inside the chrome://extensions/ manager, not in a separate
tab. Obviously browser internal pages are inaccessible for extensions,
but frames with PDF files may appear on any site.

You may find more not so obvious cases like "action" popups.

The "page" menu context for inaccessible documents may be useful in a
limited number of cases, however the "link" context provides URL
suitable for notes. So context menu appearing almost everywhere,
including other extensions, may be reasonable.

[Robbi]

Hi @Max

I haven't yet thought of an extension that interacts with PDF files but I'll try to remember your considerations.

As for the options page anchored to the extensions page, I seem to remember having had a few little problems in the past and that's why I set it aside.

Regarding my proposal to limit the scope of the menu (e.g. div \ table) I'll let my thoughts settle for a while longer and gather any feedback this group might want to give in the meantime.

Maybe in a couple of months if I think it's still worthy of consideration I'll propose it as a feature request.

As bad as it goes, they'll reject it  at lightning speed, giving me a reason :-)

[Max Nikulin]

On 07/07/2023 15:24, Robbi wrote:
>
> Regarding my proposal to limit the scope of the menu (e.g. div \ table)
> I'll let my thoughts settle for a while longer and gather any feedback
> this group might want to give in the meantime.

That thread has so general subject, so I hardly can avoid temptation to
request more changes (e.g. to make contextMenus methods returning
Promise objects similar other Manifest V3 citizens or to adopt
menus.getTargetElement).

On the other hand I do not expect active feedback in this group.

[Robbi]

> On the other hand I do not expect active feedback in this group. <

Why you're saying that?
I have always get good advice from this group. From time to time good answer\advice cames delayed, but I am convinced the best extension\addon "intelligentia" lives here.