Closed Bug 1290117 Opened 4 years ago Closed 4 years ago

chrome.tabs.sendMessage callback isn't called when the handler is present but doesn't answer

Categories

(WebExtensions :: Untriaged, defect)

50 Branch
defect
Not set

Tracking

(firefox51 fixed)

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: sixtyten, Assigned: kmag)

Details

(Whiteboard: triaged)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

In the content script:
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    if (request === "ping") sendResponse("pong");
})

in the WebExtensions debugger:
chrome.tabs.sendMessage(<active tab's id>, "ping", answer => console.log("answer to ping", answer))
chrome.tabs.sendMessage(<active tab's id>, "gnip", answer => console.log("answer to gnip", answer))


Actual results:

With the content script code present and running (therefore, with a listener present):
answer to ping: pong
answer to gnip: <not logged>

Without the content script code present nor any other listeners present:
answer to ping: undefined
answer to gnip: undefined


Expected results:

With the content script code present and running (therefore, with a listener present):
answer to ping: pong
answer to gnip: undefined

Without the content script code present nor any other listeners present:
answer to ping: undefined
answer to gnip: undefined
What is Chrome's behavior here? This behavior is deliberate in the callback-based version of the API (the Promise version resolves to undefined when there is no reply), presumably because that's the behavior we observed on Chrome.
Flags: needinfo?(sixtyten)
Chrome's behavior is the same as the expected results (I've verified this again just now).

Right now this is not critical for me since the code that uses this deals with a problem I only have in Chrome[1], but it's still an incompatibility and Chrome's answer behavior is arguably more useful.

[1] outside the scope of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=36400 - this is not something firefox needs to be bug-compatible with. See also the workaround: http://stackoverflow.com/a/11125591
Flags: needinfo?(sixtyten)
(In reply to sixtyten from comment #2)
> Chrome's behavior is the same as the expected results (I've verified this
> again just now).

OK, that does seem like the more reasonable behavior.

> [1] outside the scope of this bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=36400 - this is not
> something firefox needs to be bug-compatible with. See also the workaround:
> http://stackoverflow.com/a/11125591

This is not an issue in Firefox. We load content scripts into existing pages
when the extension starts up.
Assignee: nobody → kmaglione+bmo
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #8778605 - Flags: review?(rob) → review+
Comment on attachment 8778605 [details]
Bug 1290117: Call sendMessage response callback when there are no replies.

https://reviewboard.mozilla.org/r/69826/#review66958

::: browser/components/extensions/test/browser/browser_ext_tabs_sendMessage.js:34
(Diff revision 1)
>                new Promise(resolve => browser.tabs.sendMessage(tabId, "respond-soon", resolve)),
>                browser.tabs.sendMessage(tabId, "respond-promise"),
>                browser.tabs.sendMessage(tabId, "respond-never"),
> +              new Promise(resolve => {
> +                browser.runtime.sendMessage("respond-never", response => { resolve(response); });
> +              }),

Nit:
```
new Promise(resolve => browser.runtime.sendMessage("respond-never", resolve)),
```
Whiteboard: triaged
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a153f865cb1f9ed33b54f1905e3d69d5d4e8123
Bug 1290117: Call sendMessage response callback when there are no replies. r=robwu
https://hg.mozilla.org/mozilla-central/rev/5a153f865cb1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.