STR: 1. Go to data:text/html,<a href="http://example.com" target="_blank">Click 2. Open RDM 3. Click link ER: New tab should open AR: Nothing happens

Most likely we need to listen for "mozbrowseropenwindow".

The same change appears to fix window.open as well using this test page: data:text/html,<script>onclick=() => window.open("data:text/html,ok");</script>

Comment on attachment 8802371 [details] Bug 1310851 - Minimal support for <a target/> and window.open in RDM. https://reviewboard.mozilla.org/r/86750/#review85916 ::: devtools/client/responsive.html/browser/tunnel.js:191 (Diff revision 1) > outer.preserveLayers = value => { > inner.frameLoader.tabParent.preserveLayers(value); > }; > > - // Make the PopupNotifications object available on the iframe's owner > + // Expose `PopupNotifications` on the content's owner global > // This is used for permission doorhangers You may comment which file depends on that, like what you did next by refering to ContentClick.jsm. Is that one to fix this? http://searchfox.org/mozilla-central/source/browser/modules/PermissionUI.jsm#256 At the end inner.ownerGlobal is going to be the global object of the reponsive.html document? May be that's worth mentioning as it will pollute it if its loaded using system principal. If it is using content it will just put that on the xray wrapper expandos. ::: devtools/client/responsive.html/browser/tunnel.js:222 (Diff revision 1) > + } > + > + // Support <a target="_blank"/> and window.open() > + // Note: This doesn't set window.opener for the new window. Let's defer that for > + // now, since content which does depend on window.opener seems outside the main > + // focus of RDM. You are not properly supporting target attribute here, it would be great to reflect that in this comment and may be also in the commit message. Something like: "minimal support of window.open() [no support of opener, nor window features] ... always act like target=_blank by opening in a new tab" ::: devtools/client/responsive.html/browser/tunnel.js:228 (Diff revision 1) > + let { detail } = event; > + event.preventDefault(); > + let uri = Services.io.newURI(detail.url, null, null); > + browserWindow.browserDOMWindow > + .openURI(uri, null, Ci.nsIBrowserDOMWindow.OPEN_NEWTAB, > + Ci.nsIBrowserDOMWindow.OPEN_NEWTAB); If you have any comment to add justifying why you are using that particular openURI() method and not any of the other possible ones (like openWindow2, ....) That could be worth mentioning!

Comment on attachment 8802371 [details] Bug 1310851 - Minimal support for <a target/> and window.open in RDM. https://reviewboard.mozilla.org/r/86750/#review85916 > You may comment which file depends on that, like what you did next by refering to ContentClick.jsm. > Is that one to fix this? > http://searchfox.org/mozilla-central/source/browser/modules/PermissionUI.jsm#256 > > At the end inner.ownerGlobal is going to be the global object of the reponsive.html document? > May be that's worth mentioning as it will pollute it if its loaded using system principal. If it is using content it will just put that on the xray wrapper expandos. Yes, I'll mention PermissionUI.jsm, good idea. Yes, `inner.ownerGlobal` in the responsive.html UI document with system principal, so there is some pollution. I added comments about this. It will also get a bit strange with multiple viewport as well... We'll cross that bridge later. > You are not properly supporting target attribute here, it would be great to reflect that in this comment and may be also in the commit message. > Something like: "minimal support of window.open() [no support of opener, nor window features] ... always act like target=_blank by opening in a new tab" Right, these are all good points. I've expanded the comments and will update commit message too. > If you have any comment to add justifying why you are using that particular openURI() method and not any of the other possible ones (like openWindow2, ....) > That could be worth mentioning! Main reasons are it's similar to path taken by regular browsing with `<a target/>` and I don't seem to get enough info from the event to use more complex ones. Something to refine later if needed.

Pushed by jryans@gmail.com: https://hg.mozilla.org/integration/autoland/rev/c0e030c0d9cb Minimal support for <a target/> and window.open in RDM. r=ochameau

I managed to reproduce this issue on Firefox 52.0a1 (2016-10-10), under Windows 10x64, using STR from comment 0. The issue is no longer reproducible on Firefox 52.0a1 (2016-10-24). Tests were performed under Windows 10x64, Mac OS X 10.11.6, Ubuntu 16.04 x64.