"a separate background script" - Is this a background script in the same frame (i.e. running in the same background page, and not some child frame)?

If so, this is intentional - sendMessage should NOT be triggered in the same frame ( bug 479425 ).

Ah, I see. In that case, I suppose this is working as designed, though it's a bit unexpected; especially because this previously did work. The scripts are separate, but they're both running on the generated background page, so that makes some sense.

It would be nice if the documentation for message passing made note of this, since it definitely isn't obvious.

Hello,

I'm facing this issue too.
Check the attached extension.

What is strange is that when I call the send message from the background and I have an onMessage listener also on the background, the callback is not called,
BUT when you click the browser action and the extension then have another page active, the listener in the background is also triggered (check the console of the bg page when you click the browser action button).

For me this does not make much sense. The onMessage listener on the bg page should either be always called or never called (when the message comes from the bg page).

My extension was relying on the message to self (I was reusing in the background messages that were sent to open pages from the extension).

Deleted: send_message_bug.zip 1.5 KB

send_message_bug.zip 1.5 KB Download

#2
> because this previously did work.

That was not intentional, and also inconsistent (e.g. if you add a callback, then the message wouldn't be delivered) (this is  issue 479425 ).

> It would be nice if the documentation for message passing made note of this, since it definitely isn't obvious.

I don't see this question popping up very often on Stack Overflow, so I guess that this is kind of obvious. For communication between parts (=pages/frames) of the extension, it would be counter-intuitive to also receive the message at the sender.

#3
> BUT when you click the browser action and the extension then have another page active, the listener in the background is also triggered

This is a bug, see  issue 597698 . The listener should not be triggered.

> I don't see this question popping up very often on Stack Overflow, so I guess that this is kind of obvious.

I can understand why it's like this (and I'm not disagreeing on that, I think it's fine the way it works now), but I don't really see how it would be counter-intuitive; as the person above me mentioned, it was actually quite useful, because it let us re-use messages across the entire application rather than having multiple ways of accessing our background functionality.

Anyway, I appreciate you responding, it cleared things up for us!

No problem. I'll close this issue since there is nothing to do here (except for fixing the bug from #4, but that is tracked separately in  issue 597698 ).

I also think this specific behavior should be added to the documentation.

If it is not there, then I will rely on testing the API myself for the behavior and assume the the test result is the correct behavior.

In this case it was exactly what happened, I tested the API to infer for undocumented behavior, assumed the result of my test was the correct behavior and build my solution over it.

Now the behavior have changed and this will sure introduce a bug in my extension that I'll have to fix, and the worse, I'll have to fix in a manner that will work regardless of the behavior from the API, as users can be using different versions of chrome...

In my opinion the way it was behaving in M48 was the correct and more intuitive.
Did you (whoever introduced the change) think before changing this, on the impact this could have if users like me relied on this behavior, which was not documented, and also not obvious?

Now I lost a bit the trust in the stability of the APIs.

> Now the behavior have changed and this will sure introduce a bug in my extension that I'll have to fix, and the worse, I'll have to fix in a manner that will work regardless of the behavior from the API, as users can be using different versions of chrome...

The "old" behavior is a bug:
1) sendMessage and onMessage in SAME frame: if callback is set, onMessage is not triggered.
2) sendMessage and onMessage in SAME frame: if callback is not set, onMessage is triggered.
3) sendMessage and onMessage in DIFFERENT frames: onMessage is always triggered (regardless of whether the callback is set).

The inconsistency between 1 and 2 makes no sense and was fixed via  bug 479425 , by not triggering onMessage regardless of whether the callback is set.
The fact that (2) happened was a bug and should not be relied upon. A fully backwards-compatible solution is to replace your call to chrome.runtime.sendMessage with a direct invocation of whatever logic you put in the chrome.runtime.onMessage handler.


> Did you (whoever introduced the change) think before changing this, on the impact this could have if users like me relied on this behavior, which was not documented, and also not obvious?

I generally try to maintain backwards-compatibility if possible (in the past I have directly contacted extension devs when I knew that an inevitable change was going to break their extensions).
In this case, I underestimated the impact - apologies for that.


> Now I lost a bit the trust in the stability of the APIs.

The documented APIs are quite stable IMO. E.g. chrome.extension.sendRequest / chrome.runtime.sendMessage have been deprecated for many years, but they are still present in the current version of Chrome.
If behavior is not documented, but you want to rely on it, open a new ticket here and/or submit a patch.

I'm re-opening this one and will submit an update for the documentation.

> In this case, I underestimated the impact - apologies for that.
Apologies accepted, as a software developer, it is sometimes hard to measure this kind of impact.

> I'm re-opening this one and will submit an update for the documentation.
Thanks

> E.g. chrome.extension.sendRequest / chrome.runtime.sendMessage have been deprecated for many years
Is chrome.runtime.sendMessage deprecated? I could not find this in the documentation.
Should I be using a newer API?

> Is chrome.runtime.sendMessage deprecated?

No, not at all. For some history on the methods, see https://stackoverflow.com/questions/11811554/chrome-extension-port-error-could-not-establish-connection-receiving-end-does/11811936#11811936

Here's the documentation patch: https://codereview.chromium.org/1874133002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2ee8e354ade9b0ad6c030c94420e61d2ca3f743f

commit 2ee8e354ade9b0ad6c030c94420e61d2ca3f743f
Author: rob <rob@robwu.nl>
Date: Wed Apr 13 23:52:43 2016

Improve documentation of extension messaging

- Document all methods and events of Port.
- Document the fact that messages have to be JSON-ifiable.
- Emphasize that "return true" have to be used (in the API docs, and
  in the messaging tutorial, because this question keeps popping up
  every week on Stack Overflow, so apparently the previous note was
  not sufficiently obvious).
- Document the lifetime characteristics of ports.

BUG= 87758 , 126486 , 328459 , 592478 

Review URL: https://codereview.chromium.org/1874133002

Cr-Commit-Position: refs/heads/master@{#387157}

[modify] https://crrev.com/2ee8e354ade9b0ad6c030c94420e61d2ca3f743f/chrome/common/extensions/api/tabs.json
[modify] https://crrev.com/2ee8e354ade9b0ad6c030c94420e61d2ca3f743f/chrome/common/extensions/docs/templates/articles/messaging.html
[modify] https://crrev.com/2ee8e354ade9b0ad6c030c94420e61d2ca3f743f/extensions/common/api/runtime.json