#589: Declarative Link Capturing
Discussions
Discussed
Jan 1, 2021 (See Github)
Alice: This is very much an "early review".
... looks promising to handle the use cases that are described
... to note that there are a narrow set of use cases in the first place
... lots of actions in capture-links, would be nice to know when to use what (e.g. examples)
... wonder how this works in mobile OSes, where one runs one app at a time
Sangwhan: There was a previous attempt to address this and that wasn't very well accepted (sw-launch)
Alice: Not clear to me whether it wasn't accepted, or just ran out of steam...
Sangwhan: Or they realised it would be too hard to implement, decided to go for a simpler API
(Alice typing a draft comment, Sangwhan reading explainer)
Sangwhan: This makes sense. Why was this not there in the first place?
Comment by @alice Jan 26, 2021 (See Github)
Hi Matt,
Thanks for bringing this to us.
We see that this is still in the early stages, but the promising things we note are:
- The list of use cases is helpful to understand the problem(s) being solved, and
- This grew out of an attempt at a more powerful, complex API which has been abandoned/postponed in favour of a simpler, less powerful API
- The list of Issues indicate that this work is still ongoing.
The use cases listed do seem very worth addressing.
It does seem like there are many options to the capture_links field - it might be nice to link each one back to a specific use case with a brief example of how it might be used in practice.
Also, it would be helpful to have an explanation of how this would be used in the context of a mobile OS which typically has one window per application. How would that interact with the new-client option?
Comment by @mgiuca Feb 26, 2021 (See Github)
Thanks for your comments @alice .
I or @alancutter will update the explainer in response. I think we can provide specific use cases for each one.
Also note that we're planning to implement these capture_links enums one-by-one, starting with new_client and existing_client_navigate. So I just put up a big list, but we can implement them (and spec them) as the need arises, rather than speculatively assuming there's a need for all of them.
Also, it would be helpful to have an explanation of how this would be used in the context of a mobile OS which typically has one window per application. How would that interact with the
new-clientoption?
We should think of this entire feature as a hint to the user agent. It doesn't have to do what you ask. Browsers are (generally) allowed to close any window / tab whenever it wants, and routinely do. So even if you ask for new_client, the mobile browser can just implement it as existing_client_navigate, destroying your existing context, which is not very acceptable on desktop but quite normal on mobile. We'll say that in the explainer.
Discussed
Mar 8, 2021 (See Github)
Tess will write feedback re: new_client behavior on platofrms that don't support multiple windows.
Discussed
Apr 26, 2021 (See Github)
Amy: privacy & security questionnaire in a google doc.
Ken: I also get access denied.
Dan: it should be a markdown file in the WICG repo along with the spec
Ken: about to ship? I think they already made changes based on my comments.
Dan: looks good to me
Hadley: makes me uneasy in the same way that changing forward and back behaviour makes me uneasy
Ken: which they're not changing
Hadley: we did talk about that at the time, uneasy rather than full on problem
Dan: one thing I like is that it's not proposing a new JS API, the declarative aspect. It's extensions to the manifest file.
Yves: I'm sure this is a use cases in miniapps, some coordination here would be good. Especially as there is a WG on that.
Dan: this goes to the manifest file...
Ken: this is going to go into incubation, Marcos does not want to add anything to manifest that isn't implemented in browsers
Hadley: just for navigating to URLs within the applications navigation scope?
Ken: if you have installed a PWA it will focus instead of opening another window.. give you control to reuse existing tabs
Hadley: one reason I use web apps vs native apps, eg. twitter, if I'm clicking on a link I'd prefer to read the article in the brower rather than in twitter's web view
Ken: this is the same origin. Twitter would create another window that would embed in iframe, it should open in a separate window. You can always right click and say open in new tab/window. I understood you could change the default on ChromeOS. Right click > always open in new window. You can control it yourself, that's nice.
Hadley: I like the scope of this.
Dan: in an ideal case this spec provides a more web like experience for web apps that make use of the manifest. What you said about twitter is why I use twitter as a PWA as opposed to the app, because I want everything I do on twitter to be in the same context as my other web browsing. I'm asking a question about visibility of browser engines.
Sangwhan: I vaguely remember seeing something analogous to this in a miniapps spec
Ken: developers and people we're talking with doing PWAs all want this
Sangwhan: I'm sure this is useful for many people
Ken: for creating app like experiences on the web it's very useful. Flexible way is to use service worker and give you full control of windows inside your domain so youc an focus them and do whatever you want. But that's not coming now, this is in between, 80% or more use cases.
Dan: wait to hear back about S&P questionnaire and check back in plenary
Comment by @rhiaro Apr 27, 2021 (See Github)
Hi, the Security & Privacy questionnaire is in a google doc that we can't access. Could you move it to a markdown file in the same repo as the explainer? Thanks!
Comment by @torgo Apr 27, 2021 (See Github)
Hi @mgiuca can you give us any visibility of other browser / engine support for this? Is this on its way to the manifest file spec itself? /cc @marcoscaceres
Comment by @mgiuca Apr 28, 2021 (See Github)
@rhiaro Moved into the explainer here. (Hmm, I'm not sure why you couldn't access the doc. It is set to "Anyone on the internet with this link can view". But anyway it's in GitHub now.)
@torgo I don't know of any other browsers who have expressed support for this.
Comment by @torgo Apr 28, 2021 (See Github)
Hi @mgiuca thanks for that! For the security & privacy questionnaire answers, can we understand that the answers to the other questions is 'no'? Also just to note: you list WebApps as a destination (presumably because this will become part of webapp manifest) however in order for that to happen there need to be multiple implementations. So I would encourage you to have those discussions with other browsers and try to generate some additional support if you want to take this out of incubation. We also think this activity needs to be coordinated with the parallel work going in in this area in the MiniApp working group. However in general we're very supportive of this feature and would like to see this move forward.
Comment by @mgiuca May 3, 2021 (See Github)
I have sent out requests for standards positions from Mozilla and WebKit:
OpenedDec 17, 2020
HIQaH! QaH! TAG!
I'm requesting a TAG review of Declarative Link Capturing for Progressive Web Apps.
New Web App Manifest members to control what happens when the user navigates to a page within scope of an installed web app.
This feature introduces the "capture_links" member, an enumeration allowing the customization of link capturing behaviour, allowing sites to:
Automatically open a new PWA window when the user clicks a link to their app.
Have a "single window mode" like mobile apps.
Further details:
This is a sibling spec to URL Handler which would allow link capturing from different origins and URLs outside of the app scope. We are collaborating with Microsoft (the primary authors of URL Handler) to make sure these two projects fit nicely with one another.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
☂️ open a single issue in our GitHub repo for the entire review (since we are currently sharing the repo with sw-launch)