Service Worker Scope Pattern Matching

Improves service worker scoping to give developers finer grained control over site control. This change also introduces a new object type to expose URL pattern patching in general. The type is introduced specifically for this change but could potentially with any arbitrary API or JavaScript in the future.

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. 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 that perform URL pattern matching. In addition to service worker scopes 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.

Documentation

Status in Chromium

Blink>ServiceWorker


No active development (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No public signals
  • No public signals
  • No public signals
  • Positive

Owner

Last updated on 2019-12-16