1258360 - Implements runtime.onMessageExternal/onConnectExternal

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P2)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

WebExtensions-based addons should be able to exchange messages with another addons by listening to messages and ports on the onMessageExternal/onConnectExternal events.

e.g.

- in the received addon:

    browser.runtime.onMessageExternal.addListener((msg) => {
      ...
    });

- in the sender addon:
   
    browser.runtime.sendMessage("[e-mail]", "example-cross-addon-message");

An addon doesn't need any special permission to be able to receive cross-addon messages/ports.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: MozReview Request: Bug 1258360 - [webext] Implement runtime.onMessageExternal and runtime.onConnectExternal. r?kmag

Review commit: https://reviewboard.mozilla.org/r/41407/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/41407/

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8732861 [details]
MozReview Request: Bug 1258360 - [webext] Implement runtime.onMessageExternal and runtime.onConnectExternal. r?kmag

Pushed for an initial feedback the proposed changes to add the currently missing runtime.onMessageExternal/runtime.onConnectExternal and to enable runtime.sendMessage and runtime.connect to work cross-addons.

In the mean time I'm looking for a reasonable strategy to add a test case for it (if I remember correctly our current test helpers refuse to install two test add-ons in the same test case) before changing it to an r?

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: MozReview Request: Bug 1258360 - [webext] Mochitest plain runtime.onMessageExternal and runtime.onConnectExternal. r?kmag

Review commit: https://reviewboard.mozilla.org/r/51349/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/51349/

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8732861 [details]
MozReview Request: Bug 1258360 - [webext] Implement runtime.onMessageExternal and runtime.onConnectExternal. r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/41407/diff/1-2/

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

In the last push on mozreview:

- "runtime.onMessageExternal/onConnectExternal" draft patch rebased and tweaked on a recent tip
- new mochitest-plain test added for the cross-addons message exchange (which ensure that the cross-addons
  message exchange happens as expected and that messages are not delivered to the wrong handlers)

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

As per discussion with Bob, it could be pretty interesting to check how the chrome addons linked to this issue (e.g. 
- Bug 1283117 related to "Adobe Acrobat" extension, 
- Bug 1283171 related to "Evernote Web Clipper" extension
- Bug 1282869 related to "Google Dictionary" extension)
are using this features, so that we know if we can split fixing Bug 1258360 from the issue described in Bug 1271663.

In particular we are interested to check:

- if the callback registered to onConnectExternal/onMessageExternal is checking the sender extension id (or if the client side of these add-ons is supposed to check the sender id when it receive a message)

- if any chrome-extension have needs to be specified in the manifest of these add-ons (or of the client side of this add-ons), as briefly discussed during MozLondon and as reported from the my notes in Bug 1272663 Comment 1)

Comment 9

[Bob Silverberg [:bsilverberg]]

In the "Adobe Acrobat" extension, onMessageExternal is used once, which can be seen at [1]. It does make use of sender.id in order to whitelist a single extension from which it can receive messages. The extension id is hardcoded into the code, and I tried searching for it by id on the Chrome web store and came up empty. It may be an unlisted extension, and it sounds from the comment and the code that it is related to testing. This would lead me to believe that the feature isn’t critical to the extension, fwtw.

In the “Evernote Web Clipper" extension, onMessageExternal is used once, which can be seen at [2]. As above, it does make use of sender.id in order to whitelist two extension from which it can receive messages. The ids of those extensions are hardcoded into the code and neither of them exist on the Chrome web store. It’s difficult to say exactly what the Evernote extension is using onMessageExternal to accomplish.

In the “Google Dictionary" extension, onMessageExternal is used once, which can be seen at [3]. It does not appear to make use of `sender` at all to filter out the extensions from which it can receive a message.

Note that I do not see anything in the manifests of any of these extensions that looks like it corresponds to an external extension.

[1] https://gist.github.com/bobsilverberg/3df985bec01f3f2872f230be8621b0ff#file-abobe-onmessageexternal-js
[2] https://gist.github.com/bobsilverberg/3df985bec01f3f2872f230be8621b0ff#file-evernote-onmessageexternal-js
[3] https://gist.github.com/bobsilverberg/3df985bec01f3f2872f230be8621b0ff#file-google-dictionary-onmessageexternal-js

Comment 10

[Hector Zhao [:hectorz]]

Hello, now that native messaging is ready for initial feedback, I'm trying to decide whether there's any API still missing for ICBC to port their banking extension[1] to Firefox.

It tries to use `runtime.onMessageExternal`, but with "externally_connectable" entry in manifest.json, it looks like it's for receiving messages from whitelisted web pages[2], will that be part of this bug? Thanks.

[1]: https://chrome.google.com/webstore/detail/icbc-chrome-extension-fro/dlombpffcodogboaljnamhpphpdkjdam?hl=en
[2]: https://developer.chrome.com/extensions/messaging#external-webpage

Comment 11

[davisford]

Hi, just curious is there a dev build I can use that has this, and Luca do you have any indication when this might land?

Thanks!

Comment 12

[Yuri Konotopov]

> It tries to use `runtime.onMessageExternal`, but with "externally_connectable" entry in manifest.json, it looks like it's for receiving messages from whitelisted web pages[2], will that be part of this bug?

Please implement this feature also.
This is needed for GNOME Shell integration web extension: https://chrome.google.com/webstore/detail/gnome-shell-integration/gphhapmejobijbbhgpjhcjognlahblep

Comment 13

[Andy McKay]

This looks like its waiting for review? Kris whats the status of this?

Comment 14

[Yuri Konotopov]

Since NPAPI support is finally disabled for all plugins except Flash, implementation of `runtime.onMessageExternal` became more impotant to retain GNOME Shell integration with Firefox.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Ping?

Comment 16

[Yuri Konotopov]

Since Firefox 50 was released we now have only one version before NPAPI plugins would be finally blocked.
There is really no time left to test webextensions with host messaging capabilities.

Please give this issue maximum priority.

Comment 17

[Andrew Swan [:aswan]]

(In reply to Yuri Konotopov from comment #16)
> Since Firefox 50 was released we now have only one version before NPAPI
> plugins would be finally blocked.
> There is really no time left to test webextensions with host messaging
> capabilities.
> 
> Please give this issue maximum priority.

It sounds like you're confusing two different APIs, this bug is about communication between different extensions and communication between extensions and web pages.  Native messaging (communication between an extension and a process other than the browser) landed in Firefox 50.

Comment 18

[Yuri Konotopov]

(In reply to Andrew Swan [:aswan] from comment #17)
> It sounds like you're confusing two different APIs

Ofcourse I meant "external messaging", not "host messaging", thanks.
GNOME Shell integration is using both those APIs so I confused them in last post.

Comment 19

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Yuri Konotopov from comment #18)
> (In reply to Andrew Swan [:aswan] from comment #17)
> > It sounds like you're confusing two different APIs
> 
> Ofcourse I meant "external messaging", not "host messaging", thanks.
> GNOME Shell integration is using both those APIs so I confused them in last
> post.

Something similar to the "externally_connectable from a webpage" can be already achieved using a content script and the special cloneInto helper (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#cloneInto)

Here is a small example that shows how to put it together using this approach:

https://github.com/rpl/webextensions-examples/tree/example/externally-connectable-contentscript/externally-connectable-contentscript

Let me know if this helps with your use case.

Comment 20

[Yuri Konotopov]

(In reply to Luca Greco [:rpl] from comment #19)
> Something similar to the "externally_connectable from a webpage" can be
> already achieved using a content script and the special cloneInto helper
> 
> Let me know if this helps with your use case.

Thanks for the hint. It's works for me.

Comment 21

[Rob Wu [:robwu]]

What's the status of this? A cross-extension communication channel is an important primitive for add-ons that wish to cooperate with each other.

Comment 22

[Michel Gutierrez]

I fully agree with you Rob. For instance, this Chrome extension, https://chrome.google.com/webstore/detail/weh-inspector/fmgamnjfcnkcpfbbgifncejeplbpoebg , cannot work on Firefox because of runtime.onMessageExternal/onConnectExternal not being available.

Comment 23

[Kris Maglione [:kmag]]

I already have a patch for this. I fixed it by accident while working on a different bug. Sorry, Luca.

Comment 24

[Andy McKay]

(In reply to Rob Wu [:robwu] from comment #21)
> What's the status of this? A cross-extension communication channel is an
> important primitive for add-ons that wish to cooperate with each other.

Its a blocker for 57, just finding the schedule for it.

Comment 25

[Andy McKay]

Do you have a patch you could upload for review Kris?

Comment 26

[Kris Maglione [:kmag]]

Attachment: Bug 1258360: Implement onMessageExternal and onConnectExternal.

Review commit: https://reviewboard.mozilla.org/r/116438/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/116438/

Comment 27

[Kris Maglione [:kmag]]

Comment on attachment 8842672 [details]
Bug 1258360: Implement onMessageExternal and onConnectExternal.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/116438/diff/1-2/

Comment 28

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8842672 [details]
Bug 1258360: Implement onMessageExternal and onConnectExternal.

https://reviewboard.mozilla.org/r/116438/#review118326

::: toolkit/components/extensions/test/mochitest/test_ext_sendmessage_reply2.html:57
(Diff revision 2)
> +    }
> +  });
> +}
> +
> +function contentScript(token, id, otherId) {
> +  let gotContentMessage = false;

Could gotContentMessage be a promise that is waited on in the following promise.all?  dito with gotTabMessage.  And the assert on those vars seems redundant.

Comment 29

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/83e85e21d35404878a2e4bb9b26f66e8b817c99b
Bug 1258360: Implement onMessageExternal and onConnectExternal. r=mixedpuppy

Comment 30

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/555710da7b9a13e20c927c8bb6adad118c79b932
Bug 1258360: Follow-up ESLint fix. r=me

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/83e85e21d354
https://hg.mozilla.org/mozilla-central/rev/555710da7b9a

Comment 32

[davisford]

Super glad to see this has been marked RESOLVED -- nice work.  Can someone comment on when it will land in the next FF version?

Comment 33

[Kris Maglione [:kmag]]

(In reply to davisford from comment #32)
> Super glad to see this has been marked RESOLVED -- nice work.  Can someone
> comment on when it will land in the next FF version?

Firefox 54.

Comment 34

[Kris Maglione [:kmag]]

This also changes the meaning of the browser.runtime.id property, which may cause issues for extensions which expect that to be the same as the ID used in their URLs.

Comment 35

[Yuri Konotopov]

Does this changed is some way how "chrome.runtime.sendMessage(chrome.i18n.getMessage('@@extension_id'), message, options)" handled?
GNOME Shell integration browser extensions broken with current nightly.

Comment 36

[Kris Maglione [:kmag]]

To the extent that the ID argument was previously ignored, yes. You can either omit the ID argument, or pass browser.runtime.id instead.

Comment 37

[Yuri Konotopov]

Kris, thanks for info.
Difference between runtime.id and i18n.getMessage('@@extension_id') a bit confusing and should be documented IMO.
I still have problems with runtime.sendMessage/runtime.id, but will proceed in IRC to not spam this issue.

Comment 38

[Yuri Konotopov]

Do I understand correctly that this change not making runtime.sendMessage work from web pages? So overall runtime.onMessageExternal functionality is not ready yet?

Comment 39

[Kris Maglione [:kmag]]

External messaging from web pages is being tracked in bug 1319168, but we're unlikely to ever implement it.

Comment 41

[Will Bamberg [:wbamberg]]

I've updated the compat data, and updated:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessageExternal
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onConnectExternal
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/MessageSender

Please let me know if we need anything else here.

Comment 42

[Will Bamberg [:wbamberg]]

> Difference between runtime.id and i18n.getMessage('@@extension_id') a bit
> confusing and should be documented IMO.

I've also added a paragraph in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Internationalization#Predefined_messages to try to clarify this.