User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Steps to reproduce: 1. Register a custom protocol handler using navigator.registerProtocolHandler. 2. Set an iframe's src to a URI of the custom protocol. Attached repro.zip which creates these conditions. To use it: 1. Serve on localhost:8000 (eg. python -m SimpleHTTPServer 8000). 2. Navigate to http://localhost:8000. A bar appears at the top; click Add Application to add the site as a handler for "web+foo" links. 3. Click "click here". A dialog appears, asking which application to use. Choose Protocol Handler Test. Actual results: The handler page ("I just handled the protocol") opens in a new tab. Expected results: The handler page ("I just handled the protocol") appears inside the iframe. Note: The spec [1] says "In the case of a registered handler being used, the algorithm will be reinvoked with a new URL to handle the request." I take this to mean that when an iframe navigates to a registered protocol handler, it should calculate the new URL and then redirect the page within the iframe, not create a new top-level browsing context. [1] https://html.spec.whatwg.org/multipage/browsers.html#navigate Works correctly in Google Chrome 46.

Note: The reason I want to do this is because I found this old Mozilla blog post by Austin King [1] and wanted to try out the technique there (create an iframe with a registered protocol, then postMessage to it, allowing communication to an unknown site selected by the user). This doesn't work in Firefox because the site doesn't open in the iframe. So I am a bit confused (maybe this actually was working in Firefox in 2010). [1] https://blog.mozilla.org/webdev/2010/07/26/registerprotocolhandler-enhancing-the-federated-web/

Out of curiosity, I downloaded Firefox 4.0.1 (April 2011) and tested my repro case. It works, so this has regressed at some point in the last four years.

Hmm, this seems to work in Firefox 41.0.1. (I'm a bit confused because although I didn't note it in the bug report, I'm sure I would have tested FF 41 before going back to FF 4.) However, it still doesn't work in Nightly 43 or 44. So I think this is a recent regression after all.

Hi Matt, I'm seeing the same problem on Firefox 52.2.0, but only on Linux. Did you get any further with it? Malcolm

Hi Malcolm, No I haven't looked at this recently. Note that I was using Linux when I tried it in 2015.

This is still broken :( Running Nightly on FreeBSD here. After the page opens in the tab, the e10s process where that happened seems to become frozen, some tabs become non-interactive. Works fine in Chromium still. BTW, This exact technique is actually used in "production" by webactions/indie-config https://indieweb.org/indie-config which is a protocol that lets others' websites configure reply/like/repost buttons by loading a frame from your website (iframe src="web+action:load").

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/e945168c87aa use browsing contexts for urifixupinfo's consumer property, r=mak https://hg.mozilla.org/integration/autoland/rev/d6c5410fc285 use BrowsingContext for external helper app handling of protocols, r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/0c7811dc2ea9 avoid loading mailto: and other standard schemes into frames, r=nika