Add manifest scope improvements doc

[LuHuangMSFT]

Describe problems app developers face with the current manifest scope model and propose a two-layer scope architecture to address them.

[dmurph]

I wonder if 2,3,4 could be combined into one thing?

E.g.:

"launch_handlers": [
  // Patterns are evaluated in order, until one applies to the url.
  { "url_pattern": <..pattern..>,
     "client_mode": "focus-existing" },
  { "url_pattern": <...pattern..>,
    "client_code": "never_capture" },
  ...
// the pattern could be for exteneded urls! so we could say that an
// extended scope, for example, never captures.

  // to maintain backwards compatibility, if none apply, the "launch_handler" entry is used as the default
],

IDK if this is better - to NOT capture something into the app, you have to specify a handler for it.

Questions here would be for backwards compatibility in general too - all solutions need to make sure that old versions or chrome don't break - e.g. the manifest parser doesn't 'throw away' the manifest if it fails to parse something here (I don't think that's the case for most of this)

[LuHuangMSFT]

Interesting. I've not thought about specifying capturing scope from launch_handlers before. Will investigate.

[LuHuangMSFT]

Do you think this current doc is solution-agnostic enough to be merged?

[dmurph]

Maybe another way to say what I said above is - maybe we can flatten the concept of the per-origin opt-in and opt-out into the same concept of specializing launch handling per url, by introducing a 'never-capture' value? But maybe there are reasons to not do that?

[mhochk]

If I'm following correctly, we're also talking about this 'layer' being where we think about a clicked link within the app, which we don't know yet if "this URL is part of the app". Small wording tweak suggestion:

Suggested change

	This layer answers: *"Now that we know this URL is part of the app, how should the browser handle it?"* This is where richer pattern matching (potentially `URLPattern`) becomes appropriate, because evaluation happens inside the browser after the OS has already routed the URL to the app.
	This layer answers: *"Now that we are in the app, how should the browser handle this URL?"* This is where richer pattern matching (potentially `URLPattern`) becomes appropriate, because evaluation happens inside the browser after the OS has already routed the URL to the app.

[mhochk]

Is URL scoping enough? I'm wondering if the app might want to factor in even more dynamic information, like "what URL is my current app page on"? (e.g. YouTube PWA wants to open a video link in the current window if nothing is playing, but if something is playing wants to pause it and open a new window).

If so, this might be more wholistically solved by giving the app more permissions within the context of its launch handler. Namely, letting it easily launch a new window of itself with params similar to the LaunchParams it received.

[mhochk]

FWIW - A browser could choose to support a more complex syntax at this layer, and attempt to best-effort translate it to the OS it is on, erring on the side of a broader capture, with a fall-back of trying to have it handled in the browser. I wouldn't recommend it for a v1, but worth considering as a potential future while designing the API shape.

So for example, on Windows or iOS/macOS the browser might try to break it into include/exclude paths with basic wildcards, whereas on Android it wouldn't have an 'exclude' option. In any case the browser would always check the URL at launch time, and if it didn't match the more complex syntax provided by the PWA it would launch it in the browser mode instead. (Or if it wanted to be super fancy, it could attempt to look up the default browser and forward it along to that. Should be possible on at least Windows, though likely not on Android/iOS).

[mhochk]

I would lean into the 'different' rather than 'subset' direction. Though a very contrived case, I could imagine wanting to capture a URL activation, but still show it as 'outside the scope of the app' in the UI. Possibly for something like an old URL location that now attempts to guide you to the new URL, but less aggressively than an automatic redirect.

Suggested change

	**What developers need.** A mechanism to define a **capture scope** that is a subset of (or different from) the application scope — controlling which URLs trigger navigation capturing independently of which URLs render in the app window.
	**What developers need.** A mechanism to define a **capture scope** that is different from the application scope — controlling which URLs trigger navigation capturing independently of which URLs render in the app window.

[dmurph]

Chat at blinkon:

• Add background sectino on scope extensions, and highlight of the intention of ux impact, app exists cross-origins, but only for user ux / user agent usability
• Maybe roll in scope extensinos mentions on problems 1,2,3, sahing that the solution must also be compatible with extended scope sitiuations
• add 'Other Considersations' section or 'Problems' or whatever section
  • "Scope Extensinos T&S Considations - Can the manifest own these extra decisinos or do the exteneded scopes need to control all scope-related features impacting viewing their urls on the PWA"

proposal from me would likely put all controls in manifest and only delegate to the scope extension the 'scope filtering' part? eg.g the scope member field and any new fields we add to modify scope for exlucsion etc, but then the 'UX behavior' bits with capturing and launch customization etc be in the manifest, and just have it able to specify url patterns or whatever that include extendeds origin. BUT - alternative should be docujented to have this be in the scope extensions dict area. We then should consult with T&S about what they think. Is this blocking? or likely ok?

adding fields to better specify scope in both manifest and scope extensions dict sounds appropriate. other origins can specify the scope more fine-grained. but the actuall UX controls over launch handlign and capturing IN that scope can not make any situation "worse" for that extended scope origin than today (from a t&s point of view) -it's just making the app more UX-robust. So it seems fine to have all of that in the manifest not need to ,say, put a 'launch_handler' member field in the scope_extensions dict.