1. Define the purpose of the protocol

Use a custom protocol to enable the browser to call up the client local program, details please click on the big man wrote the article: Universal URL Protocol implementation in the browser to open the native arbitrary program.

How to detect the existence of custom protocols in practical applications? Internet Explorer can detect registry keys through ActiveX, what should Chrome do? Of course, there is a solution. Some people have encapsulated this function into generic JS, so let’s learn more about it.

2 source analysis

The source code of ProtocolCheck.js is compatible with different browsers. The important part is this section:

 function openUriWithTimeoutHack (uri, failCb, successCb) {
     var timeout = setTimeout(function () {
        failCb()
        handler.remove()
     }, 2000)

     // handle page running in an iframe (blur must be registered with top level window)
     var target = window
     while(target ! = target.parent) { target = target.parent }var handler = _registerEvent(target, 'blur', onBlur)
     function onBlur () {
        clearTimeout(timeout)
        handler.remove()
        successCb()
     }
     window.location = uri
  }
Copy the code

The function takes three parameters

  • Uri: URL of the local client to be invoked
  • FailCb: turns on the callback when the client fails
  • SuccessCb: Turns on the client success callback

Set a 2 second timer (the time can be adjusted according to the specific project), and use window-location to open the URI, because the page will be out of focus after the URI is opened, so you can monitor the window blur event. If the window blur event is captured, the custom protocol is considered to exist, and the local client is opened. Then call the successful callback function, and clear the timer, etc., if 2 seconds after the page is not caught out of focus, you can think that the custom protocol does not exist, open the local client failed, call the failed callback.

3. Pit record

Some problems were actually found in the project practice:

  1. Sometimes both the client is opened and a failed callback is performed.

Reason: It’s not hard to see the problem by looking at the source code. The implementation of blur detection is not 100% reliable, it may take a while to enable the local client, sometimes it is slow for a variety of reasons, it is possible to open after 2s, but the code considers that the client failed after 2s, so it will automatically execute the failure callback.

Solution: There is no perfect solution to this problem, can only set the time a little longer, as far as possible to avoid this situation. However, the user experience is not good, the user needs to wait a while to see the logic of the failure callback, resulting in a feeling of stalling. So you have to get the timing right.

  1. Cannot detect the presence of a custom protocol using protocolcheck.js for a child window opened with window.open

The reason: Handle page running in an iframe (blur must be registered with top level window); blur events must be registered with top level window.

Instead of using window.open, create a new route and check whether the custom protocol exists. Or save this state after the parent window detection is completed, and use it directly in the child window.

4. Used in projects

1. Download the file

Git address: protocolcheck.js.

I put the js file in the static folder of the vue project.

2. The introduction of

Add to the index.html file

<! DOCTYPEhtml>
<html>
  <head>.<script src="/static/protocolcheck.js"></script>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>
Copy the code

Open the Console, enter window, and see that the protocolCheck has been mounted to the window, you can use.

Use 3.

openMultiDisplayWebview () {
  let expandScreenUrl = 'xxxxxx'
  try {
    window.protocolCheck(expandScreenUrl, function () {
      console.log('Protocol not registered')... })}catch (e) {
   // Catch the exception}}Copy the code

Article reference JS detection custom protocol