msLaunchUri does not work reliably

Not reproducible Issue #7181860


Guillaume R.
Apr 12, 2016
This issue is public.
Found in
  • Microsoft Edge
Found in build #
Reported by 2 people

Sign in to watch or report this issue.

Steps to reproduce

On some computers only, the msLaunchUri API does not work (nothing happens after calling the method, no success or error callback).

  1. Register a custom URI scheme in the system
  2. Use the msLaunchUri on Edge to launch it, adding a trace to the success and error callbacks
    Expected: a prompt (Yes|No) is displayed to the user, asking whether he meant to switch app. Or the error callback to be called on failure.


1 attachment

Comments and activity

  • Microsoft Edge Team

    Changed Assigned To to “Christian F.”

    Changed Status

  • Hello,

    This item appears to be a duplicate of an existing item of feedback and will be closed out to reflect this. Please follow the existing item here for updates on this issue:

    All the best,
    The MS Edge Team

  • Changed Status

  • As James M. from the MS Edge Team said in #6761763, the problem with the success callback needs to be treated in a separate bug, which is this one => reopening.

  • Microsoft Edge Team

    Changed Assigned To to “James M.”

    Changed Assigned To from “James M.” to “Steven K.”

    Changed Assigned To to “Balaji B.”

    Changed Assigned To to “wwatri”

  • Adding the same comments here from the duplicated bug 6761763.

    These are the four cases being tracked.  The expected results for cases #1 and #2 are assuming using your test code or a similar alerting test case (see the attached repros and README).

    1. protocol handler available AND only one AND a callback is provided
         > “supported” pop-up

    2. no protocol handler available AND a callback is provided
         > “unsupported” pop-up

    3. no protocol handler available AND a callback is not provided
         > should be a dialog to select an application to handle the request

    4. multiple protocol handlers available AND a default is not selected.
         > should be a dialog to pick a default application

    Cases #1 and #2, which I believe was the main point of your bug submission, correct me if I am wrong, are fixed and are available in latest insider fast build, “the Creator’s Update.”

    The Edge Team

  • Microsoft Edge Team

    Changed Assigned To from “wwatri” to “Jameson L.”

    Changed Status to “Confirmed”

    Changed Status from “Confirmed” to “Not reproducible”

  • Hello,

    Thank you for providing this information about the issue. After thorough testing, we are now unable to reproduce this problem in Edge. Please test this behavior in our latest insider build 16215.

    Best Wishes,
    The MS Edge Team

  • I found the following issue using navigator.msLaunchrUri with Edge 41.16299.248.0

    If you call msLaunchUri on a protocol that has never been registered, then it works as expected. If you type this in the console:

    navigator.msLaunchUri('neverregistered://', function(){console.log('yes')}, function(){console.log('no')})

    You get a no, which is correct.

    If you register a protocol, launch it in Edge, and then remove the protocol, it seems like Edge “caches” the protocol, and it thinks is still there, even though it has been removed. In this case, when you type:

    navigator.msLaunchUri('removedprotocol://', function(){console.log('yes')}, function(){console.log('no')})

    The console prints a yes (incorrect) and then a "You’ll need a new app to open this [protocol]" dialog show up, prompting you to get the app in the store. IE11 just prints no.

    This behavior is different from IE11 and also from the specification and it makes msLaunchUri an unreliable method in Edge.

  • Following up with my comments above, it seems like Edge looks not only at HKEY_CURRENT_USER\Software\Classes for the protocol, but also at HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\ProtocolExecute\.

    This second key is created by IE11 if you happen to trigger the protocol from it.

    If we remove only the first key, Edge wrongly thinks the protocol is still present, and it calls the successCallback instead of the noHandlerCallback.

    The workaround is to remove the ProtocolExecute key from the registry if present.

  • I am facing this problem in EDGE the error callback is not getting called instead it shows a popup asking user to select an app to open such applications in case the protocol is not registered.
    The registries as mentioned by Daniel P doesn’t exist but still I am getting this problem.

    It was working fine till last month looks like some recent update has again broken it.

    Would appreciate any update on this.

You need to sign in to your Microsoft account to add a comment.

Sign in