I've been playing around with this and so far so good, but...

[ddumont]

I know this is named launchParams, but I was really hoping this would be able to get any navigation (even from other windows) and let me decide if they should open in my app or not.

What if someone clicks on a link to the app from another website, or I want to support integration with other platforms?
If those links are crafted to go to different parts of my website.

So for instance, I have an installed pwa on http://localhost right now. Clicking this link here doesn't open the app. I think it should.
I wouldn't mind using the serviceworker for this. It would be really nice if there were an event that I could capture the navigation and either direct the load to the app (and be able to safely focus the window to the front) or let it continue in a new tab.

[bathos]

The non-goals section of the explainer’s second item is:

Configuring whether link navigations into the scope of a web app launch the web app (this is out of scope and may be handled by a future version of the Declarative Link Capturing spec).

The link goes to a proposal that says it was obsoleted by this proposal, which is pretty confusing! However it also has a link to a google doc, PWA Link Capturing and URL Handling: The New Taxonomy (last updated 2021-07-15 at the time of writing this), which says:

Link capturing: allowing an app to capture links clicked within its scope. In addition:

• Registering web apps to capture links opened by the operating system, not just clicks from within the browser.
• Sites won’t request this feature; it is something that browsers can do unilaterally for all web apps. If needed, we can let sites opt in/out of it, but that is not part of current plans.
• TODO: Gather a link to some additional documentation for this feature.
• TODO: Feedback that it isn’t clear that link capturing isn’t actually a developer-facing spec, it’s a user-facing choice. Make it clear that we don’t plan to publish a spec.

(italics mine)

If I’m reading that right, it’s been intentionally omitted and left as a user-agent-defined behavior. But the web-app-launch explainer also has a “link capturing” link that points at a different proposal for declarative link capturing, Web App Link Handling Manifest Options which contradicts (or updates? but you have to check the dates to work that out) the google doc. That proposal would introduce a new manifest member, handle_links, which could be set to preferred to (if I understand right) express a preference that absent other signals or user preferences, the standalone application should be used to handle link navigations.

It’s tough to sort out what the current story is based on the readme here because of the (seemingly) circular obsoletion, conflicting info, and the similar names used for the proposals. Since it looks like Web App Link Handling Manifest Options is exactly what we’re looking for, though, hopefully that proposal is considered current and the explainers for Web App Launch Handling and the old Declarative Link Capturing are just out of date?

[ddumont]

I'm glad I'm not the only confused one here :)

[alancutter]

Configuring whether link navigations into the scope of a web app launch the web app (this is out of scope and may be handled by a future version of the Declarative Link Capturing spec).

Oops! This spec really shouldn't be linking to a spec that literally says "This API proposal is obsolete in favor of launch_handler." I'll fix that up.

Yes this is intended to be a user agent feature, it currently exists on Chrome OS (the user can set a preference to always open links in an app) and your app will be launched and receive LaunchParams.

[tomayac]

(Edge has implemented "handle_links", and you can choose via edge://apps how links to the app should be handled.)