The devtools page doesn't belong to the internal context of the extension so it can't listen to chrome.runtime.sendMessage, it's more like a content script in a sense that it runs instances alongside each tab it's shown for. The documentation you've linked contains an example of correct communication: devtools page should connect to the background page using a long-lived port connection so that both parties can send and receive messages. The documentation also contains an example of communication between a content script and a devtools page. 

I agree though, the documentation could be enhanced. 

droland@ Could you please provide us with any sample extension, so that will be helpful in better triaging this issue.

Thanks!

Thank you for providing more feedback. Adding requester "jbanavatu@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

Unfortunately I don't have a sample extensions to provide. I'm working on one but it's early stage. The behavior described in my report is fairly simple to test. If you can create a devtools extension page, and add an onMessage or onConnect listener in that page, you'll see it's never triggered. From woxxom's response above, it seems this is the expected behavior (so it's not a bug). If that's the case, I think it would be useful to clarify the documentation. It's confusing that the docs say that devtools pages have access to the same runtime api as content scripts. It's true that devtools pages can add listeners to runtime.onMessage/onConnect, but as far as I can tell, it serves no purpose. Why not state directly in the documentation that devtools pages cannot use onMessage/onConnect events? Or better yet, throw an exception when a listener is added?

Here are a few stackoverflow posts related to the topic that I found while working on this problem myself. The posts contain code samples where the poster adds a listener to runtime.onMessage/onConnect in a devtools page and tries to understand why it's never called. I think the docs confuses api users (at least they confused me).

https://stackoverflow.com/questions/11661613/chrome-devpanel-extension-communicating-with-background-page

https://stackoverflow.com/questions/25999067/chrome-runtime-connect-from-content-script-and-devtools-page-js-failing-to-conne

https://stackoverflow.com/questions/42863801/chrome-devtools-extension-send-message-from-background-to-currently-open-tab-onl

https://stackoverflow.com/questions/17508634/communicating-between-chrome-devtools-and-content-script-in-extension

Thanks for the report, and feedback in comment #2.  Perhaps it could be clearer in the docs that communication between the background page and the DevTools page is done through ports.  The Developer site already has an example to illustrate how this should work under "Messaging from Content Scripts to the DevTools Page", but maybe we can update the writing.  kayce@, what do you think?

The description of communicating with the background by calling runtime.connect (or runtime.sendMessage) from a devtools page is clear from the example you reference. What confused me is whether I should assume that example represented the only way to communicate between the background and a devtools page. 

Since the documentation states that devtools pages have access to the same chrome.runtime API's as a content script, it seemed reasonable to hope that devtools pages could add listeners to chrome.runtime.onMessage/onConnect, just like a content script. And the devtools page can add listeners. But the devtools listeners will never be called, while the content script listeners will.

If the documentation made clear that devtools pages must initiate the connection/message, and that devtools pages cannot listen for connections/messages, that would reduce confusion, I think. I also wonder why the API allows for adding listeners from a devtools page, but I guess that doesn't really matter.