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

Scope Extensions: Allow for path exclusions #105

Open
jacobamills opened this issue Jul 13, 2024 · 7 comments
Open

Scope Extensions: Allow for path exclusions #105

jacobamills opened this issue Jul 13, 2024 · 7 comments
Assignees
Labels
scope-extensions https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

Comments

@jacobamills
Copy link

In scope_extensions-explainer.md#future-extensions the following is mentioned as a possibility:

  • More specific scoping e.g. scope suffix or include/exclude lists or URL patterns.
    • To be able to apply these more specific scoping rules to the primary scope (including exclusion). One possible approach is to have the primary origin specified in the scope_extensions list and have it override the behaviour of scope.

For Google Meet, this is a blocker for us to be able to enable link capturing, as there are specific paths within our application that we do not want our PWA to handle.

Because our meeting codes are defined on the root path (e.g. meet.google.com/aaa-bbbb-ccc), we would specifically need path exclusion, rather than just inclusion. For example, we would want to be able to:

  • include: meet.google.com/aaa-bbbb-ccc
  • exclude: meet.google.com/about
@jacobamills
Copy link
Author

@dmurph Thank you for reaching out to me about this proposal

@LuHuangMSFT FYI

@LuHuangMSFT LuHuangMSFT added the scope-extensions https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md label Jul 13, 2024
@dmurph
Copy link
Collaborator

dmurph commented Jul 15, 2024

Amazing, thank you for this use-case! This is incredibly valuable.

@LuHuangMSFT I think this matches with our previous convo. Notes are here

General conclusion currently:

  • The above use-case and general behavior seems to be wanted for all scopes, not just extensions or the 'manifest scope'
  • So to solve this, we will have a separate 'exclusions' field that is used on top of the manifest scope AND the scope extensions.
  • We looked into per-platform capabilities (like Android and iOS) and something like url pattern seems totally incompatible with them. However, prefix-based solutions seem supported. prefix-based exclusion is supported on iOS, but not (yet) on Android.

Something kinda like this is the conclusion:

"scope": "https://www.example.com/app/",
"scope_extensions": [
       { "type": "origin", "value": "https://helpcenter.example-help-center.com" }
]
"scope_exclusions": [
  // This apples to all origins, so this removes any url with the prefixes:
  // https://www.example.com/app/scope/
  // https://helpcenter.example-help-center.com/app/scope/
  "/app/about/",

  // These only apply to the specific origins
  "https://helpcenter.example-help-center.com/abcd/"
  "https://www.example.com/app/phone-numbers",
]

Spec psuedo:

When evaluating if a url is controlled by the app (in scope of the app), the url must be within the manifest scope or the extended scope, but cannot be within scope exlusions.

possible psuedo algorithm:

To evaluate if a url is within scope of an app:
- set is_in_scope to false
- If the url is within the manifest.scope, set is_in_scope to true
- Else if the url is within the manifest.scope_extensions, set is_in_scope to true
- for each manifest.scope_exclusion |exclusion|
  - If url.path()  starts with exclusion, set is_in_scope to false
  - If url starts with exclusion, set is_in_scope to false.
- return is_in_scope

@HowardWolosky
Copy link

@dmurph - Is there a reason why scope_exclusions wouldn't follow the same format as scope_extensions?

@dmurph
Copy link
Collaborator

dmurph commented Jul 15, 2024

@HowardWolosky said:

@dmurph - Is there a reason why scope_exclusions wouldn't follow the same format as scope_extensions?

It can - if we want to make it extensible with the "type" and "value" fields, that can totally work. "type" maybe is "path_prefix" and "url_prefix"? That might make more sense for devs. We can totally iterate on design there.

I think the main "pro" of having this be separate from scope_extensions is that it seemed less confusing to:

  • Have this be a different concept - "Why are exclusions in extensions?"
  • Make it more clear this applies to both the extension entries AND the manifest scope.

But - if everyone else things we should just put this in the scope_extensions with types like "excludePathPrefix" and "excludeUrlPrefix", then I'm OK with that too.

@dmurph
Copy link
Collaborator

dmurph commented Sep 4, 2024

We have another use-case here from a partner:

@vatanaggarwal
Copy link

Adding to what Dan mentioned, it would be ideal for an app to specific paths which are capturable. e.g. https://other.domain.com/app and everything else is non-capturable.

@dmurph
Copy link
Collaborator

dmurph commented Sep 5, 2024

@vatanaggarwal said:

Adding to what Dan mentioned, it would be ideal for an app to specific paths which are capturable. e.g. https://other.domain.com/app and everything else is non-capturable.

At that point this gets more complicated - if we're doing both inclusions & exclusions, the UrlPattern solution becomes more interesting maybe, but I know discussions there ended up stalling in the past as it got complicated. There is also compatibility with other OS's to consider here and @LuHuangMSFT I believe has the most expertise. I think, for example, Android supports some stuff with basic patterns and prefixes. I'm not sure what you can do on iOS.

@LuHuangMSFT LuHuangMSFT self-assigned this Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope-extensions https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md
Projects
None yet
Development

No branches or pull requests

5 participants