Matt Giuca Reporter
	Description • 9 years ago

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.

	Matt Giuca Reporter
	Comment 1 • 9 years ago

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/

	Matt Giuca Reporter
	Comment 2 • 9 years ago

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.

	Matt Giuca Reporter
	Comment 3 • 9 years ago

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.

	Malcolm
	Comment 4 • 7 years ago

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

	Matt Giuca Reporter
	Comment 5 • 7 years ago

Hi Malcolm,

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

	Val Packett
	Comment 6 • 6 years ago

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").

	Pulsebot
	Comment 14 • 4 years ago

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