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

PWAs as URL Handlers #552

Closed
1 task done
LuHuangMSFT opened this issue Aug 21, 2020 · 11 comments
Closed
1 task done

PWAs as URL Handlers #552

LuHuangMSFT opened this issue Aug 21, 2020 · 11 comments
Assignees
Labels
Resolution: overtaken for example another proposal has emerged which covers the same use cases and enjoys broader support Review type: CG early review An early review of general direction from a Community Group

Comments

@LuHuangMSFT
Copy link

Saluton TAG!

I'm requesting a TAG review of Progressive Web Apps as URL Handlers.

"Native applications on many operating systems (Windows, Android, iOS, MacOS) can be associated with http(s) URLs. They can request to be launched as URL handlers when associated URLs are activated. For example, a user could click on a link to a news story from an e-mail. An associated native app for viewing news stories would automatically be launched to handle the activation of the link. Web developers would be able to build more compelling PWA experiences with stronger user engagement if PWAs could request to be URL handlers through their web app manifests."

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Web Applications Working Group
  • Existing major pieces of multi-stakeholder review or discussion of this design: Github issues
  • Major unresolved issues with or opposition to this design: compatibility with Declarative Link Capturing proposal
  • This work is being funded by: Microsoft

You should also know that...

We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback

@LuHuangMSFT LuHuangMSFT added Progress: untriaged Review type: CG early review An early review of general direction from a Community Group labels Aug 21, 2020
@hober hober self-assigned this Aug 24, 2020
@hober hober added this to the 2020-09-07-f2f milestone Aug 24, 2020
@kenchris
Copy link

kenchris commented Sep 1, 2020

@marcoscaceres @anssiko you probably want to have a look at this

@kenchris
Copy link

kenchris commented Sep 1, 2020

I got a bit confused by

            "exclude_paths": [
                "/only/for/partnerapp/*"
            ]

Does this mean that the partnerapp (in this case) cannot be developed as a PWA?

@LuHuangMSFT
Copy link
Author

LuHuangMSFT commented Sep 3, 2020

@kenchris Thanks for asking. That exclude pattern says that the app at https://contoso.com/manifest.json has permission to capture all paths except for paths matching "/only/for/partnerapp/", i.e. https://tenant.contoso.com/only/for/partnerapp/. There is no special significance to that particular path pattern. I just wanted to illustrate that the origin may want to allocate URLs to be handled by different apps.

There's no reason why https://tenant.contoso.com/only/for/partnerapp/ cannot itself be the scope of a PWA (although the origin would then probably not want to allow other apps to handle those URLs). There is also no reason why the PWA at https://partnerapp.com/manifest.json would be hampered.

@LuHuangMSFT
Copy link
Author

Quick fyi for visibility: I just merged a small PR to the explainer which mainly adjusted the manifest and association file JSON format for this feature.
WICG/pwa-url-handler#17

@plinss plinss removed this from the 2020-09-21-F2F-Cork milestone Oct 14, 2020
@hober hober changed the title [TAG review request] PWAs as URL Handlers PWAs as URL Handlers Jan 27, 2021
@kenchris
Copy link

kenchris commented Jan 27, 2021

I think it makes sense to use the pattern from https://github.com/WICG/urlpattern/blob/master/explainer.md for this @wanderview

At least for allowed urls or disallowed urls

@wanderview
Copy link

FWIW I suggested that in WICG/pwa-url-handler#21.

@kenchris
Copy link

"There is one use case that we wish to address in this explainer: URL activation in native applications."

I think this should also work for installed web applications such as Progressive Web Apps if the URL is out of scope

@ylafon
Copy link
Member

ylafon commented Jan 27, 2021

Also, the goals seems to be matching what the MiniApp WG wants to define, I suggest discussing with them as well (ping @xfq)

@LuHuangMSFT
Copy link
Author

LuHuangMSFT commented Jan 28, 2021

I think it makes sense to use the pattern from https://github.com/WICG/urlpattern/blob/master/explainer.md for this

I'll open a PR asap to edit the explainer so we can see what it looks like using URLPattern.

I think this should also work for installed web applications such as Progressive Web Apps if the URL is out of scope

I think url_handlers and web-app-origin-association is able to support this. However, I think this behavior falls under navigation capture and would like to see the in-scope version of it enabled with Declarative Link Capturing first.

Also, the goals seems to be matching what the MiniApp WG wants to define, I suggest discussing with them as well

Thanks for the connect. I'll review the group charter and docs.

@kenchris
Copy link

kenchris commented Sep 15, 2021

Hi there, how does this relate to https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

That document says:

The Scope Extensions proposal is intended to be a replacement for the URL Handlers proposal with the following changes:

We assume that this means that this proposal is now not moving forward?

@atanassov atanassov added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus and removed Progress: in progress Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Sep 15, 2021
@atanassov
Copy link

We took another look this during our Gethen vf2f plenary. At this point we are closing this review since it has been already overtaken by the new work on scope extensions. Thank you for working with us. We look forward to reviewing the new proposal.

@atanassov atanassov added the Resolution: overtaken for example another proposal has emerged which covers the same use cases and enjoys broader support label Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: overtaken for example another proposal has emerged which covers the same use cases and enjoys broader support Review type: CG early review An early review of general direction from a Community Group
Projects
None yet
Development

No branches or pull requests

7 participants