-
Notifications
You must be signed in to change notification settings - Fork 58
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
Comments
@marcoscaceres @anssiko you probably want to have a look at this |
I got a bit confused by
Does this mean that the partnerapp (in this case) cannot be developed as a PWA? |
@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. |
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. |
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 |
FWIW I suggested that in WICG/pwa-url-handler#21. |
"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 |
Also, the goals seems to be matching what the MiniApp WG wants to define, I suggest discussing with them as well (ping @xfq) |
I'll open a PR asap to edit the explainer so we can see what it looks like using URLPattern.
I think
Thanks for the connect. I'll review the group charter and docs. |
Hi there, how does this relate to https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md That document says:
We assume that this means that this proposal is now not moving forward? |
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. |
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:
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
The text was updated successfully, but these errors were encountered: