1804856 - Proposal: registerProtocolHandler() support triggering events in service worker

Status: RESOLVED INVALID

(Firefox :: Untriaged, enhancement)

Description

[han.guokai]

Steps to reproduce:

This is a proposal or feature request.

Expected results:

I propose that registerProtocolHandler() support triggering events in service worker instead of navigating to page.

This is related to navigator.registerProtocolHandler() and service worker, so I also added an issue in their spec's bug tracker:
https://github.com/whatwg/html/issues/8596
https://github.com/w3c/ServiceWorker/issues/1665

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, Firefox 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", "https://example.com/add?uri=%s", {type: 'service-worker', navigation: 'none'});

// in service worker of example.com
self.addEventListener("protocol_handler", e => {
let protocol = e.protocol; // "magnet"
let link = e.originalLink; // the %s part
});

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

This is a spec feature request to change existing web platform behavior, the appropriate venue for discussion at this time is the standards bodies and it's premature to file an issue here; we are involved in the relevant standards bodies and specs and can participate there.

Comment 2

[han.guokai]

Hi, I understand. But please read https://github.com/whatwg/html/issues/8596 . A standards guy (domenic) suggest me open bugs on browser vendors's bug trackers. So I did it.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 4

[han.guokai]

Hi, Andrew

Thank you for your reply!

1. PWA "protocol_handlers"
   https://developer.chrome.com/articles/url-protocol-handler/
   This is a declarative way. It is easy, 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 1) and 2) are both declarative way, and are not general(universal) solution.

My proposal is expand registerProtocolHandler and let service worker to handle click event.
This is a programmatic solution. This approach is more flexible and leaves it up to the developer to manage how it is handled. It is very similar to handle notification in service worker. And it can works for installed 1) PWA, 2) non PWA(general web), and 3) browser extensions (Chrome MV3 is service worker based, and Firefox now support event page).