registerProtocolHandler support triggering events in service worker instead of navigating to page

[hanguokai]

(I post this on both service worker spec #1665 and whatwg spec here)

I want to compare the behavior of web apps(and browser extensions) and native apps for a registered protocol.

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 doesn't be closed or navigate to other page, you can continue to click other links in the page and active the native app again.

Web behavior

Current registerProtocolHandler() spec says the behavior is "Navigate an appropriate navigable to resultURL". In other words, the current page is unload and navigate to another page. In some scenarios, this behavior is not expected, instead users expect the behavior like native apps.

Proposal

I hope registerProtocolHandler() support another behavior like native apps behavior. When users click a registered protocol link, fire an event with the link information in service worker, then the website(web app) handle it in service worker. 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.

[domenic]

In other words, the current page is unload and navigate to another page

Why do you think that's an accurate rephrasing of the spec? The spec allows the browser to choose; there's no requirement that "the current page" (whatever that is) is chosen.

[hanguokai]

Why do you think that's an accurate rephrasing of the spec? The spec allows the browser to choose

My intent is not to explain the spec, but to describe current browser behavior. At present, Chrome navigate the page to registered URL. If <a target="_blank">, Chrome open the target URL in new tab, but developers can't control these websites.

[domenic]

Ah, OK. If you want to change browsers, I suggest you open bugs on their bug trackers. This is the bug tracker for the specification.

[hanguokai]

I want to proposal a new behavior, because the spec doesn't describe the detailed behavior what happen when click the link. It is not a browser bug.

[domenic]

Right. The spec does not mandate browser UI behavior. Each browser gets to choose that. If you want them to change it, you need to engage with them.

[hanguokai]

To support different behaviors, the api may need to add a new parameter. For example, registerProtocolHandler(scheme, url, behavior_type). Is this related to the spec?

[domenic]

I don't think so; I think browser vendors are able to implement the behavior you want with the current spec. But sure, we can reopen the issue to see if that's what browser vendors want. Again, you need to engage them to find out.

[hanguokai]

you need to engage them to find out.

Ok, I will also file bugs in browser vendors' bug trackers.

[hanguokai]

I added issues in Chrome and Firefox's bug trackers respectively: chromium-1399753 and mozilla-1804856. Because Safari doesn't support registerProtocolHandler, I didn't add issue for Safari.

Sync some information. For now, this is not a detailed design, but to ask whether browser vendors would like to support this function.

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
}); 

[hanguokai]

Below is Andrew(Firefox)'s reply:

I think the situation may have changed as your most recent posts specifically propose making changes to the registerProtocolHandler API that also adds an event to the ServiceWorker spec. The overall use case potentially could involve browser-level decisions, as it sits at the nexus Progressive Web apps/Web App Manifest, web extensions, browser-specific protocol handler mechanisms, and then also registerProtocolHandler and Service Workers. But the github issues you link are now specifically about registerProtocolHandler and service workers and get into security/privacy concern territory if a ServiceWorker could be launched without any user visible use of the underlying origin, etc.

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.

For Firefox/Gecko, we just expand it to be an https link which we do have clear behaviors around, and I think we currently are very much WONTFIX on changing this at this time for websites proper to be any different than if the link had been an https link in the first place. There may be more flexibility in the web extension space where Firefox extension manifests explicitly support protocol_handlers, but I think we are trying to standardize in the web extension space as well and so that is likely something we would try and operate through the working group for.

[hanguokai]

Here is my extended explanation.

1. PWA "protocol_handlers"

https://developer.chrome.com/articles/url-protocol-handler/
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"

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/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 can works 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).

[hanguokai]

In WICG/web-app-launch#86 , the owner would like to support "launch_handler": { "client_mode": "service-worker" } in PWA manifest launch_handler in the future.

Let me further explain why the current click behavior (navigation behavior) on custom protocol link is not ideal. Traditional web page links are used to display a content for human, but some other URI protocols are not designed for human to see. For example, magnet link is designed for adding a download task in BitTorrent clients, it is not designed for human to see something. These links are not suitable for navigating to a register page. Instead, handling these links in the background is the best way.