Closed alancutter closed 2 years ago
Out of interest, do you think this should support UrlPatterns assuming it gets standardised?
Even if not, would it be possible to add support for them later without breaking things for existing sites? Ideally, we wouldn't have an exclude_paths
and an exclude_patterns
property.
I'm really pleased you guys are working on this 😄 I encountered a use case for this quite recently in a mobile app I was building.
Our client had a news website where the urls of articles were in this form:
<scheme>://<origin>/title-of-article/articleId
But there were a number of pages we wanted to exclude, like /about
, /wp-login
and /ts-and-cs
. This was super difficult to do on Android (where I believe they only have include rules, albeit include rules for patterns).
On that note, I'd be interested to see how feasible this is on Android. Presumably in cases where the link is navigated to in the browser any set of filters can be applied, as we know what rules the app cares about. However, for third party apps, they'd be limited to the filtering rules which the OS supports.
Good thoughts re UrlPatterns. I had a chat with @wanderview and concluded that exclude_patterns
would work fine for this API (and scope_extensions) if we use the reduced syntax that service workers plan to use.
Whether we start with exclude_paths
first and add exclude_patterns
later is yet to be decided though. I don't mind the overlap too much TBH.
You are correct about issues with Android (this affects Android on Chrome OS too). I think it's not unreasonable for this feature to just not work on platforms that don't support capture exclusion, it's not much different to not having support for the field at all.
The handle_links proposal is the right place for this behaviour. The launch_handler proposal is about what happens once an app is launched rather than the specific ways launches get triggered.
cc @LuHuangMSFT for visibility on this discussion.
Some sites wish to disable link capturing for certain URLs within their scope e.g. an /about page. This could in theory be handled by the sw-launch event but this is probably a generic enough use case to warrant a declarative solution.
Possible syntax: