Intent to Prototype: Service Worker Scopes Pattern Matching
Ben Kelly
Contact emails
Explainer
https://github.com/wanderview/service-worker-scope-pattern-matching/blob/master/explainer.md
TAG Review
https://github.com/w3ctag/design-reviews/issues/417
Summary
The goal of this effort is to improve the service worker scoping mechanism to give developers finer grained control over which sites are controlled.
In addition, the explainer currently proposes creating a new object type to expose URL pattern matching in general. This object is currently proposed as URLPattern. It would be usable with the service worker API, but could also be used with other web APIs or standalone with javascript.
This effort was discussed at TPAC 2019. The general sentiment seemed positive to me, but there were a number of questions about how ambitious we should be with URLPattern. It's unclear what kind of pattern syntax would be useful for many use cases, but also implementable with reasonable effort in browsers.
I would like to do some prototyping to help get a more concrete idea about the complexity of different approaches before attempting to spec a particular approach. The intent is not to lock us into a particular approach at this stage, but to better understand the constraints and tradeoffs.
Motivation
We have heard from multiple partners that the service worker scoping mechanism does not work well when there are multiple products hosted under a single origin; e.g. `example.com` vs `example/com/feature`. Currently it uses a simple prefix matching algorithm which can easily cause one team's service worker to take control and affect the service worker of a different team. There are a number of risks associated with this that are outlined in the explainer. The main goal is to allow fine grained service worker scoping to address this issue.
In addition, there are a number of places in the web platform beyond service worker scopes that perform URL pattern matching. Pattern matching is also done in at least CSP and WebNFC. It's conceivable that new features will also need to do this in the future. Rather than have each web API design its own pattern matching it would be nice to have a unified primitive that could be reused.
Finally, web developers do a lot of URL pattern matching in javascript as well. It's unclear if we can provide the same features they currently use in existing libraries, but it would be nice if we could provide this capability directly in the platform.
Risks
Interoperability and Compatibility
The explainer discusses feature detection and fallback support in Web App Manifest.
Edge: No Signals
Firefox: No Signals
Safari: No Signals
Web / Framework developers: Positive feedback from partners regarding service worker scope changes.
Ergonomics
As stated above the URLPattern object could be used with service workers, other web APIs like WebNFC, and possibly by developers directly. We are a bit uncertain about how the ergonomics will play out, though, which is why I'd like to do some early prototyping.
Activation
The URLPattern could be polyfilled, but integration with service worker scopes could not.
Debuggability
Service worker and manifest scopes are displayed in devtools. This UI surface would need to be updated to understand the new pattern-based scope definition.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Link to entry on the feature dashboard
https://chromestatus.com/feature/5519762375311360
Requesting approval to ship?
No