Documented API function 'navigator.msLaunchUri' not present in Windows 7 - by Katana314

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 864863 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 5/1/2014 6:55:32 AM
Access Restriction Public

Description

The MSDN documentation mentions a Javascript function called "msLaunchUri", apparently introduced in Internet Explorer 10, that will allow you to launch a URL with a custom scheme, such as "myapp:performAction/5". The key difference between this and a simple URI link is that if the user does not have "myapp" installed, it will simply call the 3rd argument, the failure function, instead of redirecting the user to a potentially-confusing error screen.

http://msdn.microsoft.com/en-us/library/ie/jj154912(v=vs.85).aspx

From my testing, it seems like this function does exist on Windows 8 computers, but if a Windows 7 computer has been upgraded to Internet Explorer 10 / 11, then it can't be found in the Javascript console. The MSDN documentation doesn't mention anything about the function being OS-specific, nor is there any recommendation of performing feature-detection of it before using it (I can't see any reason why it would be related to Modern UI, for instance).

It is possible that the issue is actually more specific than simply all Windows 7 computers - but all the ones I've tried have it. They may have some aspect in common, in which case I would be happy to try and help pinpoint the cause.
Sign in to post a comment.
Posted by bart bartera on 5/6/2014 at 1:15 PM
OK, so IE 9- using various workarounds & conditional commenting I can tell if a custom protocol is installed without blowing up my user's session. In IE 10+ on Windows 8 I can use this method. A check to see if this method isn't present isn't a workaround to the problem ==>> How do I tell if a particular custom protocol is installed without getting my user sent to a worthless error page for IE 10+ on windows 7?
Posted by Katana314 on 5/5/2014 at 4:02 PM
No, that should be all! Thanks.
Posted by Microsoft on 5/5/2014 at 12:27 PM
Hello Katana314,
Thank you for your feedback!
As Eric Lawrence previously mentioned, this api was not included in Windows7 and we apologize that the documentation
was not 100% clear on this.

Is there anything else we can assist with regarding this issue?

Best Regards,
The Internet Explorer Team
Posted by EricLaw [ex-MSFT] on 5/2/2014 at 2:17 PM
The IE documentation writer has filed a bug to update MSDN. Thanks for reporting.
Posted by Katana314 on 5/1/2014 at 8:39 AM
Okay. I did find that page in my research, but if you take the wording of that last paragraph at face value, there's nothing indicating that the function was made OS-specific. I'd also think for completeness, it would be very helpful for future web developers if the MSDN documentation I linked made it explicit that Windows 7 users do not have that function available. (And perhaps, for a best article, it could suggest alternatives like Version Vectors!)

Your comment has also helped since I didn't realize that Version Vectors were disabled in Windows 8! As long as this function is available, it should fill our needs, so I will feature-detect and put that to use instead.
Posted by EricLaw [ex-MSFT] on 5/1/2014 at 7:36 AM
This API, which was introduced for IE10 due to Windows 8 changes, probably *should* be available in IE10/11 on Windows 7 but it is not.

There's a bit of history at the bottom of http://blogs.msdn.com/b/ieinternals/archive/2011/07/14/url-protocols-application-protocols-and-asynchronous-pluggable-protocols-oh-my.aspx but the overall story is that this API was added because Win8 & IE10 increased the importance of AppProtocols (as a mechanism to invoke Store applications or desktop handlers) at the same time as they disabled the common mechanisms used to discover that such protocols were installed (e.g. userAgent tokens, Version Vectors, ActiveX controls, etc). As a consequence, the new API was introduced as a means of resolving that conflict. The API was deliberately knee-capped to limit the privacy risks.