Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Implements runtime.onMessageExternal/onConnectExternal

RESOLVED FIXED in Firefox 54
(NeedInfo from)

Status

()

Toolkit
WebExtensions: General
P2
normal
RESOLVED FIXED
a year ago
27 days ago

People

(Reporter: rpl, Assigned: kmag, NeedInfo)

Tracking

(Blocks: 2 bugs, {addon-compat, dev-doc-complete})

unspecified
mozilla54
addon-compat, dev-doc-complete
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 fixed)

Details

(Whiteboard: triaged)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments)

(Reporter)

Description

a year ago
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("receiver-addon@mozilla.org", "example-cross-addon-message");

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

Updated

a year ago
Blocks: 1252215
(Reporter)

Comment 1

a year ago
Created attachment 8732861 [details]
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/
Attachment #8732861 - Flags: review?(kmaglione+bmo)
(Reporter)

Comment 2

a year ago
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?
Attachment #8732861 - Flags: review?(kmaglione+bmo) → feedback?(kmaglione+bmo)
(Reporter)

Updated

a year ago
Assignee: nobody → lgreco
(Reporter)

Updated

a year ago
Status: NEW → ASSIGNED

Updated

a year ago
Whiteboard: triaged

Updated

a year ago
Duplicate of this bug: 1269124
(Reporter)

Comment 4

a year ago
Created attachment 8750302 [details]
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/
Attachment #8750302 - Flags: review?(kmaglione+bmo)
Attachment #8732861 - Flags: feedback?(kmaglione+bmo) → review?(kmaglione+bmo)
(Reporter)

Comment 5

a year ago
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/
(Reporter)

Comment 6

a year ago
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)

Updated

a year ago
Duplicate of this bug: 1253643
Blocks: 1280062
Blocks: 1066890
Blocks: 1280399
No longer blocks: 1280399
Blocks: 1281823
Blocks: 1283117
No longer blocks: 1281823
Blocks: 1283171
Blocks: 1282869
(Reporter)

Comment 8

a year ago
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)
Flags: needinfo?(mwein)
Flags: needinfo?(bob.silverberg)
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
Flags: needinfo?(bob.silverberg)
Blocks: 1281882
Blocks: 1283160
Flags: needinfo?(mwein)
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
(Reporter)

Updated

a year ago
No longer blocks: 1252215

Comment 11

a year ago
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

11 months ago
> 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
Blocks: 1303905

Comment 13

10 months ago
This looks like its waiting for review? Kris whats the status of this?
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: needinfo?(kmaglione+bmo)
Priority: -- → P2

Comment 14

9 months ago
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.
Ping?

Comment 16

8 months ago
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

8 months ago
(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

8 months ago
(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.
(Reporter)

Comment 19

8 months ago
(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.
Flags: needinfo?(ykonotopov)

Comment 20

8 months ago
(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.
Flags: needinfo?(ykonotopov)
(Reporter)

Updated

8 months ago
See Also: → bug 1319168

Updated

7 months ago
webextensions: --- → +
Blocks: 1332408

Comment 21

5 months ago
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

5 months ago
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.
(Assignee)

Comment 23

5 months ago
I already have a patch for this. I fixed it by accident while working on a different bug. Sorry, Luca.
Assignee: lgreco → kmaglione+bmo
Flags: needinfo?(kmaglione+bmo)

Comment 24

5 months ago
(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

5 months ago
Do you have a patch you could upload for review Kris?
Flags: needinfo?(kmaglione+bmo)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 28

5 months ago
mozreview-review
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.
Attachment #8842672 - Flags: review?(mixedpuppy) → review+
(Assignee)

Comment 29

5 months ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/83e85e21d35404878a2e4bb9b26f66e8b817c99b
Bug 1258360: Implement onMessageExternal and onConnectExternal. r=mixedpuppy
(Assignee)

Comment 30

5 months ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/555710da7b9a13e20c927c8bb6adad118c79b932
Bug 1258360: Follow-up ESLint fix. r=me
https://hg.mozilla.org/mozilla-central/rev/83e85e21d354
https://hg.mozilla.org/mozilla-central/rev/555710da7b9a
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54

Comment 32

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

Comment 33

5 months ago
(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.
Flags: needinfo?(kmaglione+bmo)
Keywords: dev-doc-needed
(Assignee)

Updated

5 months ago
Attachment #8750302 - Flags: review?(kmaglione+bmo)
(Assignee)

Updated

5 months ago
Attachment #8732861 - Flags: review?(kmaglione+bmo)

Updated

5 months ago
Depends on: 1344701
(Assignee)

Comment 34

4 months ago
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.
Keywords: addon-compat

Updated

4 months ago
Depends on: 1348598

Comment 35

4 months ago
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.
(Assignee)

Comment 36

4 months ago
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

4 months ago
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

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

Comment 39

4 months ago
External messaging from web pages is being tracked in bug 1319168, but we're unlikely to ever implement it.
(Assignee)

Updated

4 months ago
Duplicate of this bug: 1271663
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.
Flags: needinfo?(kmaglione+bmo)
> 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.
(Assignee)

Updated

2 months ago
Duplicate of this bug: 1362748
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.