Custom protocol handler (registerProtocolHandler) can't be opened in iframe
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: mgiuca, Assigned: Gijs)
References
Details
(Keywords: regression)
Attachments
(5 files)
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.
Reporter | ||
Updated•9 years ago
|
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/
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.
Reporter | ||
Updated•9 years ago
|
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.
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
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.
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").
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.
Assignee | ||
Comment 8•4 years ago
|
||
I think I have a fix for this.
Assignee | ||
Comment 9•4 years ago
|
||
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Comment 11•4 years ago
|
||
Assignee | ||
Comment 12•4 years ago
|
||
Depends on D74434
Assignee | ||
Comment 13•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #10)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=25e3d86183895102355cd06e91a22646f3cc44e0
Hm, missed some sites due to writing the patch on Windows, and I've realized that we need to keep windowcontext around in order to get the correct dialogparent; otherwise some download-related code breaks.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=783beb80f01ab6f617f61f2607f1caeeebe50787
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
Comment 15•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e945168c87aa
https://hg.mozilla.org/mozilla-central/rev/d6c5410fc285
https://hg.mozilla.org/mozilla-central/rev/0c7811dc2ea9
Updated•4 years ago
|
Description
•