While reading the Chris Coyier’s post Application-Specific Links the other day, I realized what has been bugging me for a long time now: a proper solution for openening a certain URL in a modern Web App.
Since the beginning of the digital age (feels like that), we have files associated to a certain application, installed on our machine, regardless if its running Windows, iOS, OS/2 or whatever. We have learned that well and no one questions it … but … the IT world keeps on turning and today we are not only talking about files, but about links.
Many modern applications are written with Web technologies, thanks to cross platform frameworks like Electron. Some of them are real apps for working on things, like the famous editor Visual Studio Code, and some are mirroring their online services in a desktop app only, like Slack or Notion. However, the latter have the problem how to deal with links to their online services. When a user is sent a link and has become accustomed to using the desktop app, it won’t open in the app as he clicks on it, but in his default browser. The question is, how to associate not only files, but links with certain desktop apps?
Triggered by Notions announcement of using a dedicated link protocol
notion:// to open up Notion links directly in the Notion App, Chris wrote about the possibilities an a Mac to associate certain URL schemes with a Web App in general. His choice fell on Choosy, an app which hooks into to the process on opening links by beeing the systems default browser and forwarding the URL to configured applications.
Fair enough, but it’s a tool for Mac. However, it was not particularly difficult to find equivalent programs for Windows 10, my preferred OS:
Interestingly, Microsoft already has something similar built into Windows, but prevents users from messing with it:
What Chris’ approach and all similar Windows programs have in common is, that they are based on executables, EXE files and yes, the cross-platform apps mentioned above are executables, but for me this is too short. What about Chromium based Progressive Web Apps (PWA)?
Since the Chromium team has introduced the possibility to add a website as desktop shortcut and start it in a new window, without any browser specific toolbars and other stuff, it became very popular, especially if this website was implemented by the developer as a PWA.It does not matter whether all PWA features, such as offline mode or similar, are available. The mere fact of being able to use an online service in its own window is a gain.
But such an app has no specific executable! It will be executed by the browser with some parameters itself. The question is, how to associate a certain URL scheme or a custom protocol with these web apps?
Some basics about how Chromium based browsers are dealing with this feature:
As you click on Create Shortcut… in the More Tools menu in Chrome or Edge and confirm the following dialog (or install the PWA), a new folder in
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Applications will be created. Its name starts with
_crx_ and is followed by a random string (so called app-id), f.e.
ffokdlainpppngbbhdcobaocmbobgdii. In this folder the Favicon of the website is stored.
If it is a real PWA and has a Web App Manifest, you will find all resources defined there in another subfolder named by the app-id below
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Applications\Manifest Resources.
The paths differ depending on which browser profile is active. In this case ‘default’.
The desktop shortcut, which will be created, points to an executable named
msedge_proxy.exe. These files are scaled-down versions of the browser executable itself. Its main purpose is to bypass a Windows error as described in its source code, in order to create a correct shortcut.
The important part of the shortcut are the calling parameters:
--app-id- the random ID generated by the browser
--profile-directory- the browser profile to use; mostly ‘default’
If you are interested, Chromium has dozens of parameters, some to change the behaviour and others only for debugging purposes. Peter Beverloo provides an automatic generated List of all Chromium Command Line Switches.
The following has nothing to do with the actual problem and doesn’t help in any way, but it was interesting to dig a bit deeper into the operating principles of Chromium.
As we saw that the browser creates a unique ID for the new shortcut, we find all needed data referenced in the file
%LOCALAPPDATA%\Google\Chrome\User Data\Default\preferences. It has no extension, but it is a JSON file.
Two sections are relevant in this file:
Holds the information how the window is displayed on the desktop (metrics).
Holds every other information about the app, including the complete manifest und the URL to show.
It is possible to edit the
preferences manually, but not advisable, because its the backbone of your browser profile and you have to restart all browser instances after changes.
There are native protocol handlers in every OS. The most famous is
mailto:. A click on such a link opens the default mail editor. Since 2006 the W3C discusses an extension called
registerProtocolHandler, every web app could implement to tell the OS, that it is responsible for a certain protocol.
If this registrations as the user enters the site for the first time, he will be asked by the browser for allowance, he has to confirm to make it work.
As the developer implements the links, he has to write it like that:
<a href="web+myfancyapp:settings">Go To Settings</a>
The registration and a click on such a link causes the browser to request
For understandable reasons some protocols are blacklisted, like mailto, irc, tel and others. Custom protocol schemes has to have the prefix
web+, in order to avoid interference with the standardized protocols. As of May 2021, it is part of the capabilities project and is in development currently.
Nice … but doesn’t helps in solving our problem in the first place, because we can’t yet break out of the browser with it. We need something to tell the browser that an installed PWA is responsible for this protocol…
There is no official W3C proposal, but experiments around the Chromium team to extend the PWA’s manifest file like that:
This could be the bridge we need to bind a PWA to a certain protocol, in order to open up the registered browser app, instead of a new tab. But its is just an experiment.
Another approach on connecting certain links to a PWA is similar to the manifests
protocol_handlers but for URL schemes. No need for registering a protocol … browser just parse the URL and show up my app:
"url_handlers" : [
Simple and straightforward. There is a Chrome Platform Page for this feature and the current status is Origin Trial for version 93!
To try it out, you can enable
#enable-desktop-pwas-url-handling in Edge and Chrome:
But … it is also not even on the way to an official proposal :|
As of today there is no solution for Windows users to associate links with the bunch of different applicationson windows, as we are used to from the files. But there is a special technique regarding web apps at the horizon, zo ease this pain, even if it depends on the app developers.
Maybe Microsoft should think about their approach of Apps for Websites, in order to make it possible for users to extend that. The cherry on top would be then, if they decide to integrate the upcoming Protocol and URL Handlers, defined by the developers, right into this tool.
- whatwg.org: HTML - Living Standard
- MDB Web Docs: Web-based protocol handlers
- Thomas Steiner (web.dev): URL protocol handler registration for PWAs
- Matt West: Registering Protocol Handlers to Intercept Special Links
- Gyuyoung: What is navigator.registerProtocolHandler?
- GitHub Issue on W3C/Manifest: Add manifest option for PWAs to be registered as scheme/protocol handlers
- MDN Web Docs: protocol_handlers
- Microsoft Docs: Experimental features in Progressive Web Apps (PWAs)
- GitHub MicrosoftEdge/MSEdgeExplainers: URL Protocol Handler Registration for PWAs