User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161124004020 Steps to reproduce: 1. Install the attached test extension. 2. Go to https://www.mozilla.org/en-US/ 3. Click the toolbar button added by the test extension. 4. Verify that an alert dialog pops up, saying "frame.js received TestMessage. URL: https://www.mozilla.org/en-US/" 5. Close the alert dialog. 6. Enter Responsive Design Mode by pressing ctrl+shift+M 7. Click the toolbar button added by the test extension again. Actual results: An alert dialog pops up, saying "frame.js received TestMessage. URL: frame.js received TestMessage. URL: chrome://devtools/content/responsive.html/index.xhtml" The alert dialog looks like those created by running `alert('test')` in the BROWSER console (which can be opened by pressing ctrl+shift+J). Expected results: The same thing as in step 4: An alert dialog pops up, saying "frame.js received TestMessage. URL: https://www.mozilla.org/en-US/" The alert dialog looks like those created by running `alert('test')` in the WEB console (which can be opened by pressing ctrl+shift+K), just as it does in step 4. Tested in a new Firefox profile. Also tested in Firefox Nightly 53.0a1 (2016-11-24) (64-bit).

This is a real problem[1] in the VimFx[2] extension. [1]: https://github.com/akhodakivskiy/VimFx/issues/840 [2]: https://addons.mozilla.org/en-US/firefox/addon/vimfx/

At the moment, it's only reproducible with e10 enabled where the new RDM is available. With the old RDM (with e10s on/off), there is no issue. I ran Mozregression and I found this range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=15f7b6d288b65d2f1c4abe7c9da7869427cb3270&tochange=0009a43ad49a316c86cdb52bcb44006b32011170 Jan de Mooij — Bug 1281529 followup - Don't call mallocSizeOf on a base class pointer. r=orange Before Bug 1281529, the new RDM called chrome://devtools/content/responsive.html/index.xhtml in the location bar instead of the URL of the website. But there was no error with the addon. Now, the website URL is displayed in the new RDM but there is the error: TypeError: tabForEvent is null[Learn More] tabbrowser.xml:5048:1 onxblDOMWillOpenModalDialog chrome://browser/content/tabbrowser.xml:5048:1 openModalWindow resource://gre/components/nsPrompter.js:364:5 ModalPrompter.prototype.openPrompt resource://gre/components/nsPrompter.js:554:9 ModalPrompter.prototype.alert resource://gre/components/nsPrompter.js:603:9 <anonymous> chrome://firefox-mm-bug/content/frame.js:2:3 Jan, your thoughts?

To start, the new RDM is only enabled in 52 and 53, so past releases should be fine. Bug 1281529 seems unrelated to me. Maybe it happens to be near the point that some RDM code was landed...? But in any event, new RDM is not really worth testing before 52, as it was still as work in progress, and many things did not work before then. New RDM currently tunnels specific messages down to the content, so add-ons sending random messages likely won't work for now. We'll need to think more about this case.

Is there a reason why the new RDM is only available with e10s?

(In reply to Loic from comment #4) > Is there a reason why the new RDM is only available with e10s? New RDM does a complex dance with tab content that was tricky to implement. Supporting it also for non-e10s would add complexity, and since it's developer focused feature and e10s is on track to be the default, it seemed okay to ship as e10s only. We could invest more time to also have it work with e10s off, it just hasn't seemed necessary so far.

Mass wontfix for bugs affecting firefox 52.

At this point, I think it's unlikely we'll do anything here to help "legacy" add-ons. However, there is a separate bug 1394841 for the same issue in WebExtensions, which would be nice to fix if possible.