I don't know why it works for you in 56.0.2987.110 because this behavior was changed intentionally long time ago in r369379 (49.0.2622.0,  issue 479425 ):

	Never connect a port to the same frame.
	Connecting to the same frame does not make sense because onMessage
	should not be triggered for the same frame.

Tested this issue on Windows-10 using chrome stable #57.0.2987.110 and older version of chrome #56.0.2888.0 by following steps mentioned in the original comment. By opening the background page in console observed there is no message called as mentioned in the step-9 on both the versions.

daniel@ Do you remember exactly on which version it used to work before? Because the provide M56 is a wrong version.

Thanks!

@brajkumar
As it happens I do. The version this definitely worked under is 56.0.2987.110.

Now the very strange thing I've noticed is that it does indeed work under versions lower than 49.0.2622.0 and above it does not, however I have only confirmed this with builds available from https://www.slimjet.com/chrome/google-chrome-old-version.php. 

However it most definitely worked on my work machine version 56.0.2987.110, the difference being that it is not a portable build of chrome, it is installed in the windows environment. This is also true for a number of other machines within my department.

The code in the example is similar to what I'm using on an internally developed extension. I can confirm that the code in question was working prior to 57.0.2987.110 on an installed version of chrome.

If I had to guess at the cause in light of the change to prevent connecting to a port on the same frame, I'd wager that the bug I've submitted is not a bug, it seems to be working as intended according to the chrome change log. Rather perhaps the Chrome update process hasn't been working correctly on multiple windows machines.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Just to confirm,

I just had a colleague test this on an installed version of Google Chrome on their own machine.

Version 56.0.2924.87 (64-bit) running under Windows 10 x64. That version is sending and receiving messages on the same frame.

Now this is a relatively easy fix in the context of my extension. I can just include my own messaging mechanism using a messaging object. 

That said, this could be a breaking change for people who have relied on this behaviour and the docs should probably be updated to reflect that.

Able to reproduce the issue on Win 10,Mac 10.12.3 and Ubuntu 14.04 using 57.0.2987.110 and canary 59.0.3054.0.
This is regressed in M49 as below.

Bisect info:
===========
good: 49.0.2621.0(369282)
bad : 49.0.2622.0(369639)
You are probably looking for a change made after 369367 (known good), but no later than 369385 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/adb4d725348d5816c78144458d8ce8ca19d3faee..bb42dee07a4a8df5dfa5ad33378b877e7b2944f3
Possible suspect:Review URL: https://codereview.chromium.org/1588533002
rob@robwu.nl : Could you please review the above and update further.

The behavior is intentional and documented (see docs of messaging and chrome.runtime.sendMessage). If you want to notify scripts in the current context, then there are many alternatives that are way more efficient than chrome.runtime.sendMessage.

The intended behavior did not always happen, but this has been fixed a long time ago (see  bug 628083 ,  bug 597698  and the bugs linked by the last bug).

@rob just as an FYI, the fact that this behaviour is exhibited in later versions when it should not is a bug, yes?

Contrary to what the report claims, onMessage is not triggered in 56.0.2924.87 (which does not differ that much from 66.0.2924.110).

#10 Can you provide the steps that you have followed to observe the behavior that you're seeing, including a sample extension and the browser version?

@rob My original report, attachment and follow up comments are accurate and I've managed to demonstrate this across multiple machines.

This behaviour is exhibited on multiple machines in my place of work spanning a few versions of Chrome which I've already specified.

I initially thought that as Chrome stop responding to onMessage events sent from the same frame that the bug was that it does not respond to the events.

It turns out that as this is intended behaviour, the bug is the exact opposite. Chrome has been responding to messages from the same frame over many updates since it was changed to not respond.

The problem seems to occur on installed (non portable) versions of Chrome that have self updated. Some versions seem to respond to messages from the same frame, it stopped working for my own machine when chrome updated itself to 57.x.

If you're testing against previous builds of chrome that are portable, the portable editions do not exhibit this behaviour. Only self updating installed versions do. So this bug may be a symptom of a problem with the self update process?

Odd. Since you say that it is already fixed in the latest version, I won't investigate it further though.

@rob considering this could be a wider more severe bug affecting millions of chrome installations globally, especially if the issue is update process related I would at least suggest entertaining the prospect of investigation of the cause. 

Bugs do not fix themselves. What if other security enhancements are also not being deployed correctly on chrome client updates? I realise this is speculation but it certainly warrants investigation to rule it out.

So are you able to consistently reproduce this issue, even on a completely new Chrome profile? If yes, provide the exact steps (maybe even archive and mail/share the Chrome version that you're using) so I can reproduce it too. Otherwise I don't have enough information to debug the issue.