1514834 - Detecting custom protocol handler works differently in Firefox

Status: RESOLVED INVALID

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

Description

[rdelay]

Attachment: firefox error.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

We have an web app that uses a custom protocol and we use a launch file to detect if it is already installed:

    function openUriUsingFirefox(uri, failCb, newInstall) {
        var iframe = document.querySelector("#hiddenIframe");
        if (!iframe) {
            iframe = _createHiddenIframe(document.body, "about:blank");
        }
        try {
            iframe.contentWindow.location.href = uri;
        } catch (e) {
            if (e.name == "NS_ERROR_UNKNOWN_PROTOCOL") {
                failCb();
            }
        }
    }


Actual results:

Since updating to version 64 we no longer get an exception therefore we never get to the failCB() function so we can prompt the user to download the app.

This was working fine in version 63 but no longer works in version 64


Expected results:

if the custom protocol is not installed it should throw the exception "NS_ERROR_UNKNOWN_PROTOCOL"

See the screen shot for version 63 exception, version 64 throws no exception

Comment 1

[Matthias Versen [:Matti]]

Can you please use our regression tool to find the change in the Firefox code that caused this ?
- https://mozilla.github.io/mozregression/

Comment 3

[rdelay]

Attachment: Mozregression error.jpg

Comment 4

[rdelay]

I have ran the tool 2 times now and keep getting an error after 9 steps.  

Error: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for c5a987b was:  Merge inbound to mozzilla-central. a=merge.  

I have uploaded a screen shot.

Comment 5

[Alice0775 White]

according to comment#3
regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8db8a228&tochange=c5a9878b

Suspect:  Bug 680300 

:timhuang
Can you please look into this?

Comment 6

[Tom Ritter [:tjr]]

So I can confirm for Tim that this is the exact expected behavior we deprecated in Bug 680300 - we wanted to remove the ability for webpages to learn if you have external applications installed (that happened to provide protocol features.)  The exception we were throwing was, as far as I know, a quirk of Firefox and a leakage onto the web that is not standardized.

rdelay, could you elaborate more on your use case? How do you accomplish the same thing in other browsers (e.g. Chrome or Edge) - I don't believe they expose this information?  Is a Web Extension something that you might support for your users?

Comment 7

[Matthias Versen [:Matti]]

confirming for now but this should be marked wontfix in case you do not want to change the behavior change from bug 680300

Comment 8

[rdelay]

So our use case is that we need to determine if our app is already installed by making a call to the custom protocol and if it fails we then prompt the user to download and install. 

If there is a way to read something other than an exception from the hidden iframe we could use that, but we haven't come up with any clever ways to do that.

As far as Chrome and IE we use a timer with a event handler for an onblur event, however in Firefox this does not work well as it continually opens the application launch window even though the app is not installed and the custom protocol is not registered..

Comment 9

[Daniel Veditz [:dveditz]]

FWIW, the fact that /something/ handles your protocol does not mean your app is installed. Could be an innocent protocol name collision, an upstart pushing a replacement app, or even something malicious.

Comment 10

[Andrew Overholt [:overholt]]

(In reply to rdelay from comment #8)
> As far as Chrome and IE we use a timer with a event handler for an onblur
> event, however in Firefox this does not work well as it continually opens
> the application launch window even though the app is not installed and the
> custom protocol is not registered..

Is this something Firefox should/could do?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Reporter, do you have some simple example code what you do on Chrome?
(But being able to detect whether a protocol handler is installed feels like a bug.)

Comment 12

[rdelay]

Here is a sample for Chrome.  Firefox opens the protocol handler box asking you to choose how to open, even though it's not installed.   


 function openUriWithTimeoutHack(uri, failCb, newInstall) {

        var timeout = setTimeout(function () {
			window.focus();
            failCb();
            handler.remove();
        }, 1000);

        var handler = _registerEvent(window, "blur", onBlur);

        function onBlur() {
            clearTimeout(timeout);
            handler.remove();
			setTimeout(newInstall, 15000);
			function newInstall(){
				window.focus();
				
				$('#newInstallLaunchMeeting').show();
				$('#launchingMeeting').hide();
				$('.notifyExecIndicatorChrome').hide();
				$('.notifyExecIndicatorFirefox').hide(); 
				  window.location = uri;
				  if(newInstall){
					  //for Chrome 
					  newInstallLoop(uri, failCb, newInstall); 
				  }
				  
				};
        }
		window.focus();
        window.location = uri;
		
    }

Comment 13

[rdelay]

Here is a sample for Chrome.  Firefox opens the protocol handler box asking you to choose how to open, even though it's not installed.   


 function openUriWithTimeoutHack(uri, failCb, newInstall) {

        var timeout = setTimeout(function () {
			window.focus();
            failCb();
            handler.remove();
        }, 1000);

        var handler = _registerEvent(window, "blur", onBlur);

        function onBlur() {
            clearTimeout(timeout);
            handler.remove();
			setTimeout(newInstall, 15000);
			function newInstall(){
				window.focus();
				
				$('#newInstallLaunchMeeting').show();
				$('#launchingMeeting').hide();
				$('.notifyExecIndicatorChrome').hide();
				$('.notifyExecIndicatorFirefox').hide(); 
				  window.location = uri;
				  if(newInstall){
					  //for Chrome 
					  newInstallLoop(uri, failCb, newInstall); 
				  }
				  
				};
        }
		window.focus();
        window.location = uri;
		
    }

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Could you perhaps even load a minimal testcase using "add an attachment".
That example seems to rely on jQuery or something?

Comment 15

[Mike Taylor [:miketaylr]]

ni? for question in Comment #14

Comment 16

[Andrew Overholt [:overholt]]

Given comment 6, I'm going to make this bug track the difference in detection we're seeing. I'm taking a stab at a better component.

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks for reporting this issue.

As comment 6 mentioned, to fix a privacy leak, we don't want to expose the discovery ability if a user has a custom protocol installed, either by a proper set of APIs or a different onblur behavior mentioned in comment 13.

Our behavior works as expected.