Manifest: Add manifest option for PWAs to be registered as scheme/protocol handlers

[fabiorocha]

Native applications often register themselves as protocol handlers to increase discoverability and usage. It would be great to have PWAs do the same via a new manifest property. The proposal here is for a new optional protocol_handlers property to be added to the manifest.

While websites do currently have this ability via registerProtocolHandler() (which for the most part just registers the browser as the handler to the OS), it would be interesting to have PWAs be first-class citizens and have the option to declare what protocols they want to handle via the manifest. They then would be launched directly when a custom-scheme link is invoked.

Explainer:

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md

Related issue:

It looks like this proposal shares some similarities with #626 (Add a means to associate a PWA with a file extension), and we should probably discuss if they should be unified or kept separate.

[FluorescentHallucinogen]

PTAL at https://github.com/chromium/ballista.

[FluorescentHallucinogen]

@fabiorocha A slightly different issue, but what about handling files and content drag'n'droped from one PWA window to another PWA window or from native app window to PWA window or from PWA window to native app window? And what about handling content pasted from clipboard?

[fabiorocha]

PTAL at https://github.com/chromium/ballista.

@fabiorocha A slightly different issue, but what about handling files and content drag'n'droped from one PWA window to another PWA window or from native app window to PWA window or from PWA window to native app window? And what about handling content pasted from clipboard?

Thanks for chiming in, @FluorescentHallucinogen. @mgiuca can correct me if I'm wrong but I think none of the proposals that spun off of project Ballista address the problem of having PWAs registered as scheme handlers. I'm trying to keep the scope very limited to that problem with this proposal, so the other questions are mostly orthogonal to the IMO, unless I'm missing something.

[samtan-msft]

Microsoft is planning to run this through the WICG with a proposal here:
https://discourse.wicg.io/t/proposal-url-protocol-handler-registration-for-pwas/4276

[fabiorocha]

Just realized that @samtan-msft's last comment said we'd take this through WICG. That was the intent but after some discussion we received feedback that this was small enough that could be taken as an issue in here directly. As shown above, I've submitted a PR against the spec but am happy to have more discussion on the proposal and iterate.

[emattias]

Will it be possible to make regular https:// links be opened in the pwa directly without having them first open the default browser and then the pwa.

The reason to override regular https:// links would be for them to gracefully fallback to opening in the browser if pwa is not installed.

Or are there other ways that custom url schemes will fallback to opening the page in the browser if the pwa is not installed?

[fabiorocha]

Will it be possible to make regular https:// links be opened in the pwa directly without having them first open the default browser and then the pwa.

The reason to override regular https:// links would be for them to gracefully fallback to opening in the browser if pwa is not installed.

@emattias thanks for the comment. I believe what you described is more related to this explainer (https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/PwaUriHandler/explainer.md), which aims to handle https links, and AFACT, that's the goal with that work.

Or are there other ways that custom url schemes will fallback to opening the page in the browser if the pwa is not installed?

I'm afraid not. Not by default at least. The page interested in having this behavior would have to have the protocol handler installed via registeredProtocolHandler for that to happen. Makes sense?

[marcoscaceres]

Removing defer while we review this...