1603737 - Protocol handler defined via manifest.json breaks pages with iframes that use it

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Marcin Rataj]

Attachment: iframe-escape-webext-protocol-demo.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

Tried to open a page with iframe loaded via protocol handler defined in WebExtension's manifest.json:

<iframe src="web+iframeb://demo"

I attach simple extension with a minimal repro.
This could be related to similar bug reported for non-Webextension registerProtocolHandler: https://bugzilla.mozilla.org/show_bug.cgi?id=1196151

Actual results:

Page loads, then iframe loads, then parent page gets replaced with the URL that should be loaded in iframe (iframe escape)

Expected results:

web+iframeb://demo should load in iframe and stay there

Comment 1

[Dietrich Ayala (:dietrich)]

To clarify, this is an iframe that is in an extension content page (web_accessible_resources), with a src value that is a custom protocol URL?

Does the breakage happen in iframes in regular web pages?

The documentation for protocol handler is not clear on which contexts are supported, only mentions "clicks" while illustrating an example.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers

Comment 2

[Marcin Rataj]

Yes, the breakage happen in iframes on regular web pages loaded via https:// as well.
(I shipped test page with extension only to make it easier to run).

Comment 3

[Shane Caraveo (:mixedpuppy)]

On a webpage, if you use navigator.registerProtocolHandler, can you use the protocol in the src of the iframe? In other words, does this reproduce using the web rather than using an extension? I ask because the protocol_handlers implementation simply uses the same underlying framework that navigator.registerProtocolHandler uses.

Comment 4

[Shane Caraveo (:mixedpuppy)]

Ooops. I'm not certain that bug 1560178 is involved after some testing.

Comment 5

[Marcin Rataj]

Yes, I can confirm, this reproduce using the navigator.registerProtocolHandler (regular web) too.

Repro:

1. Open https://ipfs.io/ipfs/bafybeigimkiixjlqjrxh5ewyjddcyrh3hfa2rakk5bnvapsy5hiisepidm/ and accept protocol handler registration for "web+ifrme://"
2. Open https://ipfs.io/ipfs/bafybeigimkiixjlqjrxh5ewyjddcyrh3hfa2rakk5bnvapsy5hiisepidm/demo.html and select the handler whenm prompted how to load the iframe URL
3. In Firefox 71 iframe content (text file with "hello") will load in the parent frame, instead of iframe

Comment 6

[:Gijs (he/him)]

This is using some ancient combination of https://searchfox.org/mozilla-central/source/uriloader/exthandler/WebHandlerApp.jsm and implementation in https://searchfox.org/mozilla-central/source/dom/ipc/ContentParent.cpp#1362 to load the resulting URI in the right frame.

It should probably just be switched to browsing contexts and this weird nsIRemoteWindow thing should be removed, I guess?

Comment 7

[Chris Peterson [:cpeterson]]

It should probably just be switched to browsing contexts and this weird nsIRemoteWindow thing should be removed, I guess?
Fission Milestone: --- → ?

Gijs, this is not a Fission bug. Are you asking whether this bug might go away if this code is ported to BrowsingContext?

Comment 8

[:Gijs (he/him)]

(In reply to Chris Peterson [:cpeterson] from comment #7)

It should probably just be switched to browsing contexts and this weird nsIRemoteWindow thing should be removed, I guess?
Fission Milestone: --- → ?

Gijs, this is not a Fission bug. Are you asking whether this bug might go away if this code is ported to BrowsingContext?

No, I'm not asking - I'm pretty sure it'll go away. This bug just seemed to tie in with the fission effort, but it's just as broken without fission so I guess we can avoid tracking it...

Comment 9

[Chris Peterson [:cpeterson]]

(In reply to :Gijs (he/him) from comment #8)

No, I'm not asking - I'm pretty sure it'll go away. This bug just seemed to tie in with the fission effort, but it's just as broken without fission so I guess we can avoid tracking it...

In that case, I'll tag this bug as "Fission Milestone == Future", meaning this bug will require some work integrating with Fission code but doesn't block shipping Fission MVP.

Comment 10

[:Gijs (he/him)]

I fixed bug 1196151, and the testcase from comment #0 works for me now.

Marcin, can you confirm this works on Nightly? ( https://nightly.mozilla.org/ )

Comment 11

[Marcin Rataj]

I tested with 78.0a1 (2020-05-27) (64-bit) and can confirm the issue is fixed, thank you!

Comment 12

[:Gijs (he/him)]

Thanks for checking!