There's no need for GM_webextSendMessage: if another extension can listen to external messages (by declaring externally_connectable in its manifest.json), userscripts and web pages can use chrome.runtime.sendMessage() directly.

@tophf No it can't, browser or chrome both are undefined.
Userscript can not access web-extension API like content-script.

I am not meaning communicate from webpage, which require specifying url in externally_connectable.matches[]
(which does not support in firefox now).
I want to communicate with the web-extension level api.

I see. We don't plan to expose WebExtensions API to userscripts. There are other extension(s) that can do it, but I don't remember the name.

We already wrap and expose some, like notification and xhr to any domain.
Maybe we can wrap and add some restriction and expose it?

I ask and publish my fork PurpleMonkey on amo several month ago.

Those are parts of the userscript API that existed for like 20 years. If you want to convince me or other userscript extension teams please provide some motivational use cases that demonstrate how it can be used.

For myself, I need this API because I want to trigger the extension SingleFile download the webpage easily.
Eg, I can put a display:fixed button on some domain with userscript, and click it to trigger the downloading.
Without this, I have to open the browser menu / open extension list / (scroll and) click SingleFile .

I write code, so I add this feature to make my life easy.
I already solve my problem, and I think maybe I can contribute back.
This is the opensource; I can add the feature I need to other's code, and other can take them back, too.

In fact, I does not use this feature often.
It does great job in 1 week, and I have not used it for months.

I know tha add a new GM_* API is a serious thing,
(though TamperMonkey has a bunch of different API.)
and new features usually mean more burden for maintainers; this is not my personal project.
Anyway, thank you all for this great add-on.

Sounds useful, but since it's the first time I see this feature being suggested, I'm not sure it should be added at all. Maybe you could open a feature request in Tampermonkey and Firemonkey? Make sure to describe the use case and the fact that this solution doesn't require externally_connectable.

I also don't like the webext part in the name. I'd probably prefer something GM_messageExtension. It would also make sense to add GM_connectExtension that uses chrome.runtime.connect + onConnectExternal.

@gera2ld, WDYT?

Sounds useful, but since it's the first time I see this feature being suggested, I'm not sure it should be added at all. Maybe you could open a feature request in Tampermonkey and Firemonkey? Make sure to describe the use case and the fact that this solution doesn't require externally_connectable.

ok

I also don't like the webext part in the name. I'd probably prefer something GM_messageExtension.

That's a better name than mine. I will use it before the PR get merged.

It would also make sense to add GM_connectExtension that uses chrome.runtime.connect + onConnectExternal.

It may take large effort to wrap the connect API since it will be a long connection,
but I have not seen any extension listens to the onConnectExternal.
I will consider on it if anyone needs this.

@connect-extension id seems simpler than @connect web-extension://id, moreover there's no technical reason we should reuse @connect.

I am also interested in this, the arguments against it don't appear to have solid footing.

A toolbox without niche, but essential, tools doesn't make for a great toolbox. Tools will be used when made available, similarly sending runtime messages is crazy useful for "hacking" your own behavior triggers into extensions via userscripts. How it can be used is not difficult to imagine, and even then, just because you may not see why someone would need a pair of side-snips, doesn't mean the tool is useless.

One hard use case for me is being able to trigger page snapshots via a userscript for an extension that only has the capability to trigger snapshots manually. I can write my own userscript to elegantly handle the automated snapshot logic, and call the extension to actually trigger the snapshot.

I have a difficult time understand the argument that "It's been this way for xxx years, why change/add?" when technology, especially web, clocks ahead at a terrifying pace every year. There will always be new, evolving, use cases as the ecosystem changes and shifts.

It's kind of a self fulfilling sort of argument:

• API doesn't have changes/additions because of the argument that it hasn't needed changes
• Perpetuating the argument that since it hasn't had changes, it doesn't need changes
• Repeat ad-infinium as more and more, potentially untrustable, forks get published to satisfy needs. Polluting the ecosystem

For anyone interested in this:
If you want to send message to other extensions on desktop, Tridactyl let you do this with the :js command.
It does not work on firefox for android so I forked violent monkey.