Closed Bug 1258360 Opened 4 years ago Closed 3 years ago

Implements runtime.onMessageExternal/onConnectExternal

Categories

(WebExtensions :: General, defect, P2)

defect

Tracking

(firefox54 fixed)

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed
Blocking Flags:
webextensions +

People

(Reporter: rpl, Assigned: kmag)

References

(Blocks 1 open bug)

Details

(Keywords: addon-compat, dev-doc-complete, Whiteboard: triaged)

Attachments

(3 files)

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.
Blocks: 1252215
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)
Assignee: nobody → lgreco
Status: NEW → ASSIGNED
Whiteboard: triaged
Duplicate of this bug: 1269124
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/
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)
Duplicate of this bug: 1253643
Blocks: 1280399
No longer blocks: 1280399
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)
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
No longer blocks: 1252215
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!
> 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
This looks like its waiting for review? Kris whats the status of this?
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: needinfo?(kmaglione+bmo)
Priority: -- → P2
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.
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.
(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.
(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.
(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)
(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)
See Also: → 1319168
webextensions: --- → +
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.
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.
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)
(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.
Do you have a patch you could upload for review Kris?
Flags: needinfo?(kmaglione+bmo)
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/83e85e21d35404878a2e4bb9b26f66e8b817c99b
Bug 1258360: Implement onMessageExternal and onConnectExternal. r=mixedpuppy
https://hg.mozilla.org/mozilla-central/rev/83e85e21d354
https://hg.mozilla.org/mozilla-central/rev/555710da7b9a
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Super glad to see this has been marked RESOLVED -- nice work.  Can someone comment on when it will land in the next FF version?
(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
Attachment #8750302 - Flags: review?(kmaglione+bmo)
Attachment #8732861 - Flags: review?(kmaglione+bmo)
Depends on: 1344701
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
Depends on: 1348598
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.
To the extent that the ID argument was previously ignored, yes. You can either omit the ID argument, or pass browser.runtime.id instead.
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.
Do I understand correctly that this change not making runtime.sendMessage work from web pages? So overall runtime.onMessageExternal functionality is not ready yet?
External messaging from web pages is being tracked in bug 1319168, but we're unlikely to ever implement it.
Duplicate of this bug: 1271663
> 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.
Duplicate of this bug: 1362748
Flags: needinfo?(kmaglione+bmo)
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.