Other issues like this say this:

Components: Platform>Extensions>API

but I still don't know how to add that to the bug report.

@natalie.grrossman: Could you please have a look at the attached screen-shot and let us know if this is the expected behavior.

Also, if the repro procedure is incorrect, provide us the screen-recording/cast for better understanding of this issue.

Thank you.

Deleted: Screen Shot 2016-07-15 at 12.50.03 PM.png 53.2 KB

	Screen Shot 2016-07-15 at 12.50.03 PM.png 53.2 KB View Download

Yes, that's it. I see that you sent the first message with another extension window open. I can see that the background received the message you sent ("echo"). This is also what I see when sending a message from any other extension window. You sent the second message with no extension windows open. There is no "echo" in the log. It's that second message that's being handled oddly, differently than is usual. I rather thought I'd see an "echo" for both messages.

It's not a very important bug. It only showed up when I tried to "reuse" the `onMessage` listener to coordinate activity within the background page itself.

Is there something more I can do to clarify the issue?

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for your report.

The expected behavior is the other way around, if you send a message using runtime.sendMessage it should only notify other parts of the extension and not scripts in the same frame.

In content scripts this was always the case; in background pages (extension pages in general) there have been bugs where scripts in the same frame were inadvertently notified. Most bugs have been fixed, but one remains (=your report and the linked duplicate bug).

This is *not* a duplicate of  bug 597698 . You said that yourself here: [1]

If that bug wasn't germaine to this issue when you responded then, then this bug certainly can't be a duplicate of that bug now. Very duplicitous of you, Rob Wu - pls undup this bug now and stop playing games.

The "expected behavior" you refer to appears to be of your own invention. It doesn't reflect the current behaviour of `runtime.sendMessage` in Chrome, described and illustrated with an example extension in this bug, nor the past behaviour of the original `extension.sendMessage` [2] - messages sent between background pages have been consistently echoed to the sender except in the singular case described in this bug report.

Chrome's documentation is entirely consistent with Chrome's current `runtime.sendMessage` behaviour [3], while your "expected behavior" is that of the old `extension.sendRequest` interface [4], which behaves differently than `runtime.sendMessage` [2]. Claiming that the documentation is wrong on this point [5] is disingenuous - you could easily have documented this "expected behaviour" yourself three months ago with proper review but did not [6].

You seem intent on rewriting this interface without consulting either your peers or the extension developers who will be affected by your changes. That is wrong. I've asked you twice now to seek clarification of this issue here before charging ahead [7], I raised the issue myself here when you seemed loathe to do it, and now I find you've suppressed the issue by quashing this bug as a spurious dup. Shame on you, Rob Wu. Restore the bug and invite some much-needed oversight.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c10
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c3
[3] https://developer.chrome.com/extensions/runtime#method-sendMessage
[4] https://developer.chrome.com/extensions/extension#method-sendRequest
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c5
[6] https://codereview.chromium.org/1874133002/
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c8, #c11

@rob@robwu.nl: Could you please look into this issue as per the request from the reporter in the comment #7

Thank you.

+Devlin (the current lead of extensions)
Natalie (the reporter) feels mistreated by my actions, please review our comments.


In response to #7

> You said that yourself here: [1]

Please don't attribute claims to me that I did not make.
In [1] I summarized the current API behavior of runtime.sendMessage in Firefox 47 and Chrome 51, and also the expected behavior (=onMessage not triggered in the same frame).

The Duplicate status means "Same root cause as another issue" (I'm not making this up - hover over the text at the left to see it yourself). Your bug report and  bug 597698  are both about the difference in behavior of sendMessage in relation with whether another extension page is open. Their root causes are identical, so Duplicate is appropriate here.


> The "expected behavior" you refer to appears to be of your own invention.

Nope, it follows the precedent set by the former owner of Extensions, as I explained in [2].


> Chrome's documentation is entirely consistent with Chrome's current `runtime.sendMessage` behaviour

It is not, see your bug and duplicate  bug 597698 .

> you could easily have documented this "expected behaviour" yourself three months ago with proper review but did not

I did, see the bottom of [2]. I admit that the documentation can be made more clear.


> You seem intent on rewriting this interface without consulting either your peers

As said in [2], I did not consult the team again because the expected behavior is already in writing by the head of the extension team.

> or the extension developers who will be affected by your changes.

On the contrary. I highly value backwards-compatibility.
You propose to "fix" this bug by "listener should continue to receive (its own) messages".
I want to fix this bug by not triggering the onMessage listener for same-frame messages even if an extension page is open (note that if there are no other pages, e.g. there is only a background page, that this "expected" behavior already occurs!).

Both alternatives can potentially break extensions.
My proposal only affects extensions that have opened another extension page.
Your suggestion affects any extension with an extension page (such as a background page, this is much more common).
Clearly implementing your proposal can potentially break way more extensions and is therefore a much higher risk to extension developers than mine.

A third alternative is to not fix this bug, but that is only confusing and the worst choice in the long term.



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c10
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1286124#c16

> My proposal only affects extensions that have opened another extension page.

...and which are messaging between those pages. That is, your proposal only affects extensions in which `runtime.sendMessage` is at all relevant. (Which, when you include popup windows, is a large domain.)

I've proposed only that `sendMessage`/`onMessage` behave the same when there is and is not a second extension page open. I prefer it be done without breaking extensions. 

Currently every extension that uses `runtime.sendMessage` to communicate between extension pages handles "echos" in some way, because the echos only stop when there is no other page to talk to. I don't know how many extensions use the echos to good advantage, but I'll guess that it's a number greater than zero. Changing the "no echo" behaviour when only one extension page is open seems least likely to break extensions; I'll guess that no extensions currently use the sound of one hand clapping to good advantage.

If you do want to change the behaviour when two pages are open and communicating, then please have a better reason than "more aesthetic" and don't act alone.

> Natalie (the reporter) feels mistreated by my actions

No Rob, I simply believe you are acting in bad faith to change the interface without consulting your peers. Since you brought it up though, we can do without the belittling sexist commentary.

Currently, we have two opposing idioms - we either dispatch the event to the same frame that it originated in, or we don't.  Whatever final decision we arrive at should ensure that we only have one behavior that developers can understand and rely upon.

I think we should enforce that the dispatching frame is never notified of its own messages.  There isn't really a use case for this, since the frame could do whatever it wanted directly - it's executing in the same JS context.  (For instance, if a developer really wanted to echo all messages, they can implement a couple line shim around chrome.runtime.sendMessage() that calls the listener directly.)

Additionally, sendMessage does significant work, despite appearing to be a simple API.  The more we can shape our APIs in such a way that it encourages developers to write performant code that results in a good user experience, the better.  Providing a sendMessage that delivers the message to the same frame is counterproductive to that point, since it results in a lot of overhead in Chrome that could (and should) have been avoided.

I think we should ensure that no messages are sent to the same frame they originated in.

First, the original and now undocumented `extension.sendMessage` behaved as `runtime.sendMessage` does now, while the deprecated `extension.sendRequest` behaves as you now say `runtime.sendMessage` should behave. Two different methods behaving in two different ways. Are you sure that was arbitrary, or was it calculated to reduce breakage in existing extensions? I suspect the latter, but I suppose it could have been a crapshoot. Do you remember who the shooter was back then?

Second, there _is_ a use case. When a content script needs some background script functionality, it must send a message saying what it wants done. If the popup or the options page needs the same functionality it can reach across to the background script's context and act directly, or it can `sendMessage` as the content script does. I prefer the latter - one access path = one point of failure, without any possible synchronous vs asynchronous issues. Well, what's good for other extension pages is good for the background script, even if it's providing the functionality. That's when I discovered the inconsistency I reported here.

More concretely, I do this in two places: I expose storage to both content and extension scripts with a common set of messages, and I connect editor controls in 1+ (extension) editor pages to editor settings in all pages the same way to coordinate changes among the editor instances. In the former case `sendMessage` is redefined in the background script to avoid this bug. Awkward, but I take your point about shimming. In the latter case editor (extension) pages respond identically to all editor messages including their own, decoupling controls and settings. Yes, that too can be shimmed, but why? It's already manufactured to tolerance.

Third, the echo is (almost entirely) irrelevant unless you're using it. If you're using `sendMessage` and the callback to do a client-server thing, you don't hear the echo because you're not listening. If you're using `sendMessage` bilaterally to communicate 2+ different things, then you're probably sending an object like `{verb: "doThis", object: "usingThis"}` and filtering on the verb. You don't hear the echo because you're already filtering messages. If each endpoint only sends one kind of message and only receives one kind of message then yes, the echo is a real nuisance and must be filtered. (I didn't find any such bug reports, though.)

Perhaps you can elaborate on "performant code" and "good user experience". Do you know of any extensions in which message rate is at all sensible to the user? I don't - the extensions I use don't send more than a couple a second, which require a couple of milliseconds to service.

Fourth (and this is important), can you please talk amongst yourselves, settle on a messaging behaviour and stop hopping back and forth, and lead out in front of the "work-alike" interfaces? This bug is not a big issue per se, but it becomes an ongoing headache if e.g. Rob "improves" the Chrome interfaces at Mozilla before raising the same issues here and `sendMessage` becomes a browser-dependent method. It'll be HTML in Internet Explorer all over again, in triplicate. (Which is more an extension developer issue and not a Chromium issue, but you can help.)

tl;dr: I prefer the current `runtime.sendMessage` behaviour; it's useful to me. It has advantages, it has disadvantages, both are slight, so do what you will but please be consistent and do what you can to keep the 'standard' in 'de facto standard'.

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

commit d93b830a957594d7ae309096d3dca344bd9abffd
Author: rob <rob@robwu.nl>
Date: Wed Aug 24 18:46:22 2016

Documentation: Clarify that runtime.sendMessage does not notify itself

BUG= 628083 

Review-Url: https://codereview.chromium.org/2272513002
Cr-Commit-Position: refs/heads/master@{#414114}

[modify] https://crrev.com/d93b830a957594d7ae309096d3dca344bd9abffd/extensions/common/api/runtime.json

Well that's just great, Rob. You changed the Chrome documentation but didn't changed the Chrome code to behave as per your revised documentation. You did though take the time to revise the Firefox code per your doc changes, so now Firefox and Chrome behave very differently and you've pissed off.

Can someone who has a stake in Chrome fix this?