User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36 Steps to reproduce: In responsive mode, Listen to message in content script And send a message from background Happens also in nightly version Actual results: Nothing Expected results: Should handle message

This is because the page loaded into a tab in responsive design mode is a developer tools page (which the extension is not allowed to access), with the actual web content loaded into a remote subframe. I'm not really sure whether we should try to handle this corner case. It affects a lot of things other than messaging.

Hi Kris, We rely on this functionality, and we have cross-browser solution which is working on Chrome Is there a simple way to solve this issue?

Similar bugs have also been filed for legacy-style add-ons back in the day, such as bug 1320159. I think it would be nice to have it working for a consistent experience, but not a major issue in the scheme of things. I think I'll move this to RDM component, because RDM is really the cause and potentially where a fix might be made.

Seems to also be an issue for DevTools extensions like React: https://github.com/facebook/react-devtools/issues/904 I think I'll investigate a bit to see how much work would be needed here.

It looks like only a small number of changes are needed to support this, so I'll give it a try.

Comment on attachment 8924341 [details] Bug 1394841 - Add WebExt messaging to RDM tunnel. https://reviewboard.mozilla.org/r/195584/#review201798 Thanks for looking into that!

Comment on attachment 8924342 [details] Bug 1394841 - Test WebExt messaging with RDM. https://reviewboard.mozilla.org/r/195586/#review201796 ::: devtools/client/responsive.html/test/browser/browser_ext_messaging.js:100 (Diff revision 2) > + let { id } = sender; > + respond({ id }); > + }); > + > + await new Promise(resolve => { > + browser.test.onMessage.addListener(resolve); Are you waiting for "resume" message? It may be helpful to comment about that here. ::: devtools/client/responsive.html/test/browser/browser_ext_messaging.js:120 (Diff revision 2) > + extension.awaitMessage("content-script-ready"), > + extension.awaitMessage("background-script-ready"), > + ]); > + extension.sendMessage("resume"); > + > + await extension.awaitFinish("rdm-messaging"); nit: for both extension.startup() and extension.sendMessage(resume) we do the action first and listen right after. This is the typical pattern to get intermittent/races. I imagine this is unlikely here. But for example it would make the wait for content-script-ready and background-script-ready easier. If you wait for them before startup you can then do: await extension.startup() await onContentScriptReady; await onBackgroundScriptReady;

Comment on attachment 8924342 [details] Bug 1394841 - Test WebExt messaging with RDM. https://reviewboard.mozilla.org/r/195586/#review202584

Comment on attachment 8924340 [details] Bug 1394841 - Check iframes for related tabs in WebExt. https://reviewboard.mozilla.org/r/195582/#review202588 ::: browser/components/extensions/ext-browser.js:38 (Diff revision 1) > - } else if (target instanceof Ci.nsIDOMXULElement) { > + } else if (target instanceof Ci.nsIDOMXULElement || > + ExtensionUtils.instanceOf(target, "HTMLIFrameElement")) { How does this work? getBrowserData only knows how to handle <browser>s that are a child of <tabbrowser> in a browser window, or belong to about:addons. Does the RDM UI have a stub gBrowser global, or something like that?

Comment on attachment 8924340 [details] Bug 1394841 - Check iframes for related tabs in WebExt. https://reviewboard.mozilla.org/r/195582/#review202588 > How does this work? getBrowserData only knows how to handle <browser>s that are a child of <tabbrowser> in a browser window, or belong to about:addons. > > Does the RDM UI have a stub gBrowser global, or something like that? Yes, the RDM UI defines a usable `gBrowser` for call sites like this that want to look up the tab for the browser frame, so that's what allows this to work here as well.

Comment on attachment 8924340 [details] Bug 1394841 - Check iframes for related tabs in WebExt. https://reviewboard.mozilla.org/r/195582/#review203018

Comment on attachment 8924342 [details] Bug 1394841 - Test WebExt messaging with RDM. https://reviewboard.mozilla.org/r/195586/#review201796 > Are you waiting for "resume" message? > It may be helpful to comment about that here. Ah right, I'll add a comment, thanks! > nit: for both extension.startup() and extension.sendMessage(resume) we do the action first and listen right after. This is the typical pattern to get intermittent/races. > I imagine this is unlikely here. > But for example it would make the wait for content-script-ready and background-script-ready easier. > If you wait for them before startup you can then do: > await extension.startup() > await onContentScriptReady; > await onBackgroundScriptReady; The extension isn't installed until `startup`, so that one should be safe. Anyway, I agree the other listeners should be moved earlier. (I am usually watching out for this anyway, but I guess I missed it here.) Thanks for catching this.

Pushed by jryans@gmail.com: https://hg.mozilla.org/integration/autoland/rev/4aa421a32de9 Check iframes for related tabs in WebExt. r=kmag https://hg.mozilla.org/integration/autoland/rev/134b46ce0aa5 Add WebExt messaging to RDM tunnel. r=ochameau https://hg.mozilla.org/integration/autoland/rev/bbf3fb8a107c Test WebExt messaging with RDM. r=kmag,ochameau

https://hg.mozilla.org/mozilla-central/rev/4aa421a32de9 https://hg.mozilla.org/mozilla-central/rev/134b46ce0aa5 https://hg.mozilla.org/mozilla-central/rev/bbf3fb8a107c