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

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

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 work. 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.

Start by reading the custom handlers section of the HTML specification and the linked WHATWG HTML issue #8596, then compare it with the Service Worker specification. Determine whether the proposed service-worker event requires a new specification design and identify the expected behavior for navigation, focus, and repeated protocol activations.