1287136 - Broken or missing "Launch Application" dialog when launched from a sandboxed iframe [NON-e10s]

Status: NEW

(Core :: DOM: Security, defect, P5)

Description

[Stefan Beyer]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

Navigate to a URI with a custom protocol (which is registered in Firefox, but "Always ask" is selected) within a sandboxed iframe.

i.e.:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
</head>
<body>
    <iframe src="other.html" sandbox="allow-popups allow-scripts"></iframe>
</body>
</html>

other.html:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
</head>
<body>
    <a href="protocol://foo">Link</a>
</body>
</html>



Actual results:

A dialog opened, which displayed an XUL error (message in German: "Diese Seite verwendet eine nicht mehr unterstützte Methode (Remote-XUL), die von Firefox standardmäßig nicht mehr angeboten wird. Bitte informieren Sie den Website-Inhaber über dieses Problem ")


Expected results:

The dialog to select an application to open the URI should be displayed.

Comment 1

[Loic]

Attachment: other.html

Comment 2

[Loic]

Attachment: index.html

Comment 3

[Daniel Veditz [:dveditz]]

What is the protocol, and how is it registered with Firefox? Is it a handler added with an add-on, or using the DOM command registerProtocolHanderl() ?

The error message seems to hint at the latter, and that your remote page is returning XUL content. XUL is not supported in Firefox anymore, and the spec for registerProtocolHandler() specifies that the remote handler should be a normal web page.

Comment 4

[Stefan Beyer]

In my case the protocol is "dynamicsnav://" which should launch an external application (the Dynamics NAV desktop client). I guess this was done during setup by the installer of the Dynamics NAV client, I did not register the the protocol by myself.

Everything works fine if I tell Firefox (in about:preferences#applications) to always open URIs of that protocol with the Dynamics NAV client, so I think the issue is not the application launch itself but the dialog in Firefox that pops up and tells me to select the program to open the URI.

Comment 5

[Stefan Beyer]

I just tested it with the "mailto://" protocol and experienced the same issue. Everything works fine if Microsoft Outlook is selected in the preferences, but if I tell Firefox to "Always ask", then instead of displaying the dialog, an error message appears (actually the window is quite small in the first place, I have to make it bigger before I see anything).

Comment 6

[Loic]

Attachment: other.html

Comment 7

[Loic]

Attachment: index.html

Comment 8

[Loic]

The funny thing is the error about "distant XUL" is only displayed with e10s disabled. If multiprocess is on (in DE or Nightly), the "launch application" dialog window is displayed fine.

Comment 9

[Daniel Veditz [:dveditz]]

When I try it on Release, or Dev Edition with e10s DISABLED I can reproduce with Loic's testcase (after setting mailto: to "ask"). In my case I don't see a broken dialog, I get nothing; I can tell it tried to open the dialog because the menu changed -- only the "Firefox" item is present unless I focus back on the open browser window. There was an error on the browser console (the separate window one, not the tab-specific one).

Works just fine if e10s is enabled. An odd result, and I kind of have to suspect it was some of the e10s work that broke this in the non-e10s case. :jimm, who should get this one?

Comment 10

[Loic]

I don't think there is a regression range to narrow down. In the past, opening the dialog from the sandboxed iframe blocked the browser, and even the computer (at least the mouse).

Comment 11

[Ryan VanderMeulen [:RyanVM]]

For the non-e10s case, can we try to see if the attached testcase ever worked? And if it did, when it stopped?
For the e10s case, it would be nice to know if this is something that's always worked or what patch caused it to start working.

Comment 12

[Liviu Cirdei]

I tried to do a regression range and this is what I found:
1. For non e10s: 
   - last good build: 2012-08-20
   - first bad build: 2012-08-21
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c676b554c7bb&tochange=abc17059522b
Note that Mozregression did't bisect on inbound builds to have a more specific regression range because it couldn't find those builds.

2. For e10s enabled it works as expected back to Nightly 35 (2014-09-11). 
Not sure if this was the first build that had e10s enabled or the first build having the option to enable it from about:preferences), but this was the first build I found using mozregression that has an option to enable e10s. If anyone knows an earlier build on which e10s is enabled, I can check on it too.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

(In reply to Liviu Cirdei [:liviucirdei] from comment #12)
> I tried to do a regression range and this is what I found:
> 1. For non e10s: 
>    - last good build: 2012-08-20
>    - first bad build: 2012-08-21
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=c676b554c7bb&tochange=abc17059522b
> Note that Mozregression did't bisect on inbound builds to have a more
> specific regression range because it couldn't find those builds.

Bug 341604 sure stands out there :)

> 2. For e10s enabled it works as expected back to Nightly 35 (2014-09-11). 
> Not sure if this was the first build that had e10s enabled or the first
> build having the option to enable it from about:preferences), but this was
> the first build I found using mozregression that has an option to enable
> e10s. If anyone knows an earlier build on which e10s is enabled, I can check
> on it too.

I'm happy calling it "since ever" as far as we're concerned here. Thanks, Liviu!