onMessage.addListener callback is missing optional sender param

[tgiardina]

Description

onMessage.addListener should take a callback with an optional sender param. Among other things, this includes vital info on which tab the message was sent from. Currently, web-ext-types does not recognize this param.

Relevant documentation

• https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage
• https://developer.chrome.com/apps/runtime#event-onMessage

Additional notes

• DefinitelyTyped has a chrome.extension namespace that solves this problem here (see line 2780).
• tabs.onUpdated.addListener - missing extraParameters #93 is a pretty similar issue.
• Is this package accepting PRs? I would gladly look at this when I have time!

[GithubGY]

Are you sure this is an issue? Because I just used it, and it worked. I also looked in web-ext-types's index.d.ts, and the parameter is there.
Since I started to look into WebExtensions no earlier than this Monday, maybe I'm missing something. Still, onMessage is an event, so you should receive that argument you are talking about through a callback parameter of addListener(), like this:

browser.runtime.onMessage.addListener((message, sender, sendResponse) => { ... });

Anyway, I have the same issue you described, but with browser.browserAction.onClicked.addListener(). But in this case it isn't really a problem, because Firefox uses a second parameter that isn't supported in any other browser.

[tgiardina]

@GithubGY Oops, you're right! web-ext-types does include onMessage.sender. That's a typo on my part. Like you, I was actually interested in the addListener callback. I edited my issue to reflect this.

But in this case it isn't really a problem, because Firefox uses a second parameter that isn't supported in any other browser.

This isn't true. Chrome also takes a second sender param (see docs or check the @types/chrome package). However, I'm not sure about other browsers. Is there a specific one that doesn't support it?'

That being said, I now see that this is more of QoL issue. After reading your comment, I refactored my code to use port.sender rather than the callback's sender param. I don't see a use case where this wouldn't work. So thanks for pointing that out.