Correction - in point 6 above, I meant "in points 2 and 3", not "3 and 4".

Tested the issue on chrome reported version 66.0.3359.117 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version and installed the extension provided in comment# 0
2) In chrome://extensions, for the extension installed, clicked on "background page", developer tools opened
3) In console entered call chrome.runtime.onMessage.addListener(()=>null); and chrome.runtime.sendMessage(null,"",null,() => console.log(chrome.runtime.lastError.message)); got the output as "Could not establish connection. Receiving end does not exist".

@Reporter: Please find the attached screencast for your reference and provide your feedback on it which help in further triaging it, could you please let us know if this issue is specific to Ubuntu 16.04, if possible please provide the screencast of the issue which help us in better understanding it.

Thanks!

Deleted: 835968.ogv 6.7 MB

	835968.ogv 6.7 MB View Download

Thanks for the response. 

You can't call sendMessage from the background when the listener is also in the background (the background doesn't receive messages sent from background, that's why you get the "can't connect message"). You should call sendMessage from a content script context (as described in point 3) if you want to do this on your own. Then continue with steps 4 to 6.

The sample extension that I provided already handles these steps. You just need to review the content devtools console after installation and loading "www.example.com" into a tab to see the message. Then edit the manifest as described in point 5 (you can use the index.html in my sample zip as devtools page) and reload extension and example.com. You should see the results as intended (no message now). Let me know if I'm not explaining clearly.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Tested the issue on ubuntu 17.10 using chrome latest stable #67.0.3396.62.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Reviewed the content devtools console after installation of "test_messaging" extension and loading "www.example.com" into a tab.
2. Observed a message in dev tools console as "The message port closed before a response was received."
3. Edited the manifest.json file by removing the line "devtools_page": "index.html",
4. Reloaded extension and example.com and observed that the extension got disabled and did not find any message in the console.

droland@ - Could you please check the attached screen cast and please let us know if anything missed from our end.

Thanks...!!

Deleted: 835968.webm 5.8 MB

	835968.webm 5.8 MB View Download

Yes, your last screen cast demonstrates the problem. From my prior experiences on this bug system, I think rob@robwu.nl might be a good person to consider this issue. He seems to know the extension messaging system well.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome latest stable #67.0.3396.62 and latest canary #69.0.3449.2.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

based on #7 comment.

TL;DR this is not specific to devtools_page. Any extension page (including iframes) without an onMessage listener will cause this issue.

Comment 6's reproduction is flawed. At the second reproduction step, manifest.json becomes an invalid JSON file (because the "devtools_page" value is removed without removing the key). Therefore any conclusions that rely on the video are invalid.

I verified that the bug exists, as follows:
1. Load extension.
2. Open example.com
3. Open DevTools console
   GOOD: Confirm that "The message port closed before a response was received." is shown.
4. Reload the page while the DevTools is still open (so the devtools_page is still open).
   BAD: The message from step 3 is not shown again.

Sanity check, to verify that the issue is caused by the mere existence of a devtools_page:
5. Open example.com in a new tab (without closing the tabs from the previous steps).
6. Open DevTools console.
7. BAD: The message from step 3 is not shown again.


When devtools_page was introduced, the devtools page ran in the process of the DevTools.
With out-of-process iframes (OOPIF) for extensions, it runs in the extension process instead.

And indeed, the same issue can be reproduced if you open a regular extension page in a new tab (e.g. chrome-extension://EXTENSIONID/manifest.json), or even a new frame in the background page.

This bug is caused by the optimization at:
https://chromium.googlesource.com/chromium/src/+/267468938e712a25010fb84ee32522a371fbbf23/extensions/browser/api/messaging/extension_message_port.cc#294

The listener in the background page ensures that port_created is true at
https://chromium.googlesource.com/chromium/src/+/90a2d3e77ac698d2b419144a8d87ed9306c1b1ac/extensions/renderer/renderer_messaging_service.cc#80

The early returns in RendererMessagingService::DispatchOnConnectToScriptContext prevent the close messages from being sent:
https://chromium.googlesource.com/chromium/src/+/90a2d3e77ac698d2b419144a8d87ed9306c1b1ac/extensions/renderer/renderer_messaging_service.cc#158

Consequently the ExtensionMessagePort does not know that all recipients have rejected the port, and the port is kept open until the page is unloaded.

I don't have time in the coming weeks to work on this, but patches are welcome.