Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add manifest option for PWAs to be registered as scheme/protocol handlers #846

Open
fabiorocha opened this issue Jan 24, 2020 · 9 comments

Comments

@fabiorocha
Copy link
Member

fabiorocha commented Jan 24, 2020

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.

image

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

@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
Copy link
Member Author

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.

@fabiorocha fabiorocha changed the title Add ability for PWAs to be registered as scheme/protocol handlers Add manifest option for PWAs to be registered as scheme/protocol handlers Feb 29, 2020
@samtan-msft
Copy link

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
Copy link
Member Author

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
Copy link

emattias commented May 4, 2020

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
Copy link
Member Author

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
Copy link
Member

Removing defer while we review this...

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 17, 2021
Adding manual WPT tests for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 23, 2021
Adding manual WPT tests for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 23, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 24, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 24, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 24, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}
pull bot pushed a commit to Yannic/chromium that referenced this issue Sep 25, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 4, 2021
…ol_handler, a=testonly

Automatic update from web-platform-tests
dwpas: Add tentative WPT test for protocol_handler

Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}

--

wpt-commits: e88c2d6ca49cb21f547ff84201659d1a39d1c4ae
wpt-pr: 30835
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 6, 2021
…ol_handler, a=testonly

Automatic update from web-platform-tests
dwpas: Add tentative WPT test for protocol_handler

Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}

--

wpt-commits: e88c2d6ca49cb21f547ff84201659d1a39d1c4ae
wpt-pr: 30835
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
Adding manual WPT test for new protocol_handler field.
w3c/manifest#846

Bug: 1019239
Change-Id: I49bbcae9ff1925fb2799d1462fca936147f2e118
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3166820
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Mike Jackson <mjackson@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#924924}
NOKEYCHECK=True
GitOrigin-RevId: 54c2e88950241d9ba236a742f7c41b1b7dcca326
@hanguokai
Copy link
Member

I have a new proposal for registerProtocolHandler() and handle click events in service worker. This is a programmatic solution (not declarative way), and should work for PWA, non-PWA(general web) and browser extensions.

You can follow it here:
whatwg/html#8596
w3c/ServiceWorker#1665

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants
@mgiuca @emattias @hanguokai @marcoscaceres @fabiorocha @FluorescentHallucinogen @samtan-msft and others