Open Bug 1196151 Opened 5 years ago Updated 1 month ago

Custom protocol handler (registerProtocolHandler) can't be opened in iframe


(Firefox :: File Handling, defect)

43 Branch
Not set





(Reporter: mgiuca, Unassigned)


(Keywords: regression)


(2 files)

Attached file Repro site.
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 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.


Works correctly in Google Chrome 46.
Component: Untriaged → File Handling
OS: Unspecified → All
Hardware: Unspecified → All
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).

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.
Keywords: regression
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?

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

I was discussing this with Tantek last weekend, in context of indie-config, and the behaviour described by the original bug is unchanged in Firefox Nightly 68.0a1 (2019-05-07) (64-bit) on macOS. CCing him here.

You need to log in before you can comment on or make changes to this bug.