A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Expand registerProtocolHandler() with service worker

hanguokai
2022-12-10

Hi everyone,

I have a new proposal about registerProtocolHandler() and service worker. I posted two issues on their spec trackers:

Current Native Apps Behavior

When click a registered protocol link, the native app is woken up and the link is passed to the app for processing. Note: the current page are not closed or navigate to other page, you can continue to click other links in the page that active the native app again.

Current Web Behavior

At present, when click a registered protocol link, Chrome navigate current page to the registered URL. In other words, current page is unload, you can’t continue to click other links in this page. In some scenarios, this behavior is not expected, instead users expect the behavior like native apps. Of course, if the link has target="_blank" attribute, browser open the target URL in a new tab, but it depends on the websites, the developers who call registerProtocolHandler() can’t control them.

At present, the spec of registerProtocolHandler doesn’t describe the detailed behavior what happen when click the link. The behavior depends on how the browser implements it.

Proposal

I hope registerProtocolHandler() can support native apps’ behavior. When users click the link, fire an event with the link information in service worker, then the website(web app) can handle it in service worker, and the current page stay there.

This approach is more flexible for developers, and the current page does not navigate to other page. For example, in service worker, developers can open a new tab or popup window, or active(focus) an already opened page or popup window to handle it.

Below is a sample code for demonstration purpose:

// in a web page of example.com
// here add a new parameter, which tell the browser fire event in service worker and don't navigate current.
navigator.registerProtocolHandler(
    "magnet", // protocal
    "https://example.com/add?uri=%s", // url
    {type: 'service-worker', navigation: 'none'} // new option object
);
// in service worker of example.com
self.addEventListener("protocol_handler", e => {
  let protocol = e.protocol; // "magnet"
  let link = e.originalLink; // the %s part
}); 

1. PWA “protocol_handlers”

This is a declarative way. It is easy to use, but only for installed PWA. Non-PWA web and browser extensions can’t use it.

2. Firefox extension’s “protocol_handlers”

Similar to PWA, it is also a declarative way, but just for extensions. There is no background event for clicking a register link.

So both 1) and 2) are declarative ways, and are not general(universal) solution.

My proposal

My proposal expands registerProtocolHandler and let service worker to handle the click event.

  1. This is a programmatic solution. This approach is more flexible (than declarative way) and leaves it up to the developer to manage how it is handled. It is very similar to handle notification event in service worker.
  2. It should work for 1) installed PWA, 2) non PWA(general web), and 3) browser extensions (Chrome MV3 is service worker based, and Firefox now support event page).