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

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

Start with the HTML Standard's custom handlers section and the linked ServiceWorker issue #1665. Compare the current navigate-to-resultURL behavior with the proposed service-worker event flow, including how link data and non-navigation handling should be specified. Done means the behavior and lifecycle are resolved in the relevant specification text.