1681249 - Firefox 83, cross-domain iframe cannot call parent window with custom url

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[herracielo]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

Iframe on different domain cannot open external application using scheme urls or for example "mailto:" when calling parent or top window location change.
window.parent.location.href = 'mailto:'
window.top.location.href = 'mailto:'

Actual results:

Nothing happens

Expected results:

External application should have been opened

Comment 1

[Andre Klapper]

Could you please provide a minimal, self-contained testcase as a HTML page (feel free to use example URLs)?

Comment 2

[herracielo]

Here is an example where a button calls window.top.location.href = 'mailto:' and a link with same content from embedded site.
It works with other browsers but not with Firefox 83.
Sorry for the poor setup but this mimics the case where page has iframed content from another domain.
https://www.w3schools.com/code/tryit.asp?filename=GLJCQDYM8WMJ

Comment 3

[herracielo]

This can be tested for example in the https://www.example.com and modify content with developer tools. Add iframe to page and switch to new iframe console and call window.top.location = 'XXXXXX' with any other value than https:// page. Mail application and perhaps spotify:// etc are not opening.

Comment 4

[herracielo]

Iframe must be in other domain than parent page to see this bug.

Comment 5

[Negritas Sergiu, Desktop QA]

Hello I have managed to reproduce the issue with de link provided in step 2. Indeed the button doesn't work with firefox 85.0a1(2020-12-14), 84.0 and 83.0 on Windows 10, macOS 10.15 and Ubuntu 20.04 . Will add this issue to a component so one of our developers could look more into it, if it's not the right component please feel free to change it to an appropriate one.

Comment 6

[herracielo]

On my tests Firefox versions prior 80 does not have this defect.

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Is this the expected behavior change of bug 1606797?

Comment 8

[:Gijs (he/him)]

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #7)

Is this the expected behavior change of bug 1606797?

Mm, sort of. The change was intended to mitigate identifying the origin of a request to open an application on the local machine, where opening the local application might expose the user to risk. This is probably not the case for most mailto: handlers, but other protocols have such risks (e.g. remote desktop and conferencing software, especially). Previously, webpages could open such links in another tab to which they had a reference (e.g. via window.opener or because they opened the tab using window.open) by navigating those browsingcontexts to the external URL. My change was intended to make this harder.

The iframe case is interesting because:

1. similar abuse of trust is possible through malvertising frames, so making this easier isn't particularly attractive.
2. it is not completely prevented by my change - if the iframe just navigates its own context (or a descendent context, ie a nested iframe inside its own frame) instead of the parent/top, then opening the link will work fine.

Finally, AIUI the spec is likely to make use of custom protocols in iframes harder, either for sandboxed iframes ( https://github.com/whatwg/html/issues/2191 ) or by requiring user interaction ( https://bugzilla.mozilla.org/show_bug.cgi?id=1672344 ) and/or using permission policy ( https://github.com/whatwg/html/issues/6111 ).

We could try to figure out if the origin of the request is from an embedded nested context in the code I added in bug 1606797, to fix this bug. But more broadly, I'm not sure if that's the right thing in the context of all the other changes. Johann/Anne, what's the latest plan here?

I'm also curious, reporter, what's the reasoning for your application to open these schemes on the parent context instead of its own or a nested context? And is your example of mailto the main thing you care about, or are you actually using this with other protocols?

Comment 9

[Anne (:annevk)]

When a cross-origin document is the initiator our rough idea was this:

• For common schemes like mailto:, always require user interaction and do not show a permission dialog.
• For other schemes, always require user interaction as well as an allow="external-protocol" Permissions Policy attribute (see https://github.com/whatwg/html/issues/6111) and show a permission dialog unless there’s a permission for the specific protocol already.
• If the iframe is sandboxed, then follow the same steps as for “other schemes” but also reject navigation unless the allow-top-navigation, allow-top-navigation-by-user-activation (with user activation) or allow-popups attribute values are present.

(From https://docs.google.com/document/d/1QD3gkQovz814uHVH9zZOQtsqqz8-nJnnO7tzQ09u2AU/edit which currently says this would only apply if the cross-origin document is being navigated, but that should really talk about it being the initiator instead, as that is what matters.)

Comment 10

[Johann Hofmann [:johannh]]

I agree with Gijs that I'd prefer to WONTFIX this unless there's a very good reason why this is needed for specific protocols like mailto:, or massive usage of this pattern in the wild. Paul, our current telemetry can't measure this, right?

Reporter, it would be great if you could share any known web breakage you're aware of that's caused by this bug.

Thanks!

Comment 11

[Johann Hofmann [:johannh]]

So I added a note to https://docs.google.com/document/d/1QD3gkQovz814uHVH9zZOQtsqqz8-nJnnO7tzQ09u2AU/edit and realized that thinking about our "ideal end state" for external protocol navigation navigating the parent should probably follow the same rules as navigating the frame itself, given that the iframe is allowed to navigate the parent already. We could just say that navigating the parent is disallowed by policy (mainly because we don't want to do the work to support it), but I'd not be comfortable doing that if other browsers behave differently.

So maybe this isn't a WONTFIX.

Comment 12

[Paul Zühlcke [:pbz]]

(In reply to Johann Hofmann [:johannh] from comment #10)

Paul, our current telemetry can't measure this, right?

Not specifically. However, when a frame navigates the parent (and the external protocol dialog is shown) we label it as the frame in our probe. That's because we look at the triggering principal here: https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/toolkit/mozapps/handling/ContentDispatchChooser.jsm#206-210
(That is assuming it's correctly set for this case).

I agree with Anne here in that we should account for the initiating context, not the context actually being navigated.
From a developer perspective, intuitively it makes sense to open the external protocol top level. However I'm not aware of any case where you'd have to do it this way?

Comment 13

[herracielo]

Hi,
For mobile and desktop browser compatibility: To open external application using schema url from a webpage that is inside iframe (or inside nested iframe) needs to call top window location change in order to trigger app switch. iOS Safari does not work unless top window href change is called.

This has worked before on all browsers I have tested but has break now with Firefox since version 80. There are certain apps that needs to be opened from web page that can be iframed and needs dynamic data passed along with the schema url. (same app for desktop and for mobile devices)

This bug now require mobile/desktop detection to get around.

I see this from a user/developer point of view as a regression from version 79 to 80 and up.

Comment 14

[:Gijs (he/him)]

Attachment: Bug 1681249 - unbreak subframes navigating ancestor frames to custom protocols, r?nika

Comment 15

[:Gijs (he/him)]

Based on the comments, I think we need to just unbreak this, and any future restrictions will want implementing separately anyway (probably earlier in the stack, as we'll need to check if there was user interaction) so we should just unbreak what bug 1606797 broke.

Comment 16

[Johann Hofmann [:johannh]]

Yeah that sounds fine for now, thanks!

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf05e23b0f9e
unbreak subframes navigating ancestor frames to custom protocols, r=nika

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/bf05e23b0f9e

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider for 85 uplift? It'd have to go directly into the RC at this point, though...

Comment 20

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #19)

Is this something we should consider for 85 uplift? It'd have to go directly into the RC at this point, though...

I'm not confident enough to uplift this straight into RC.