Preserve explicit referrer policy when the service worker reconstructs asset requests for cache-busted and redirected asset fetches.
For example, an application can load a script or image with referrerPolicy: 'same-origin' or 'origin' to limit referrer data. Dropping that policy can expose more of the current URL to that resource host.
Preserve referrer metadata when the service worker reconstructs asset requests for cache-busted and redirected asset fetches.
For example, an attacker with access to asset host logs could receive a reset token embedded in a page URL if the reconstructed request falls back to default referrer behavior instead of carrying referrer: ''.
Removes `Authorization`, `Cookie`, and `Proxy-Authorization` headers when a request is redirected to a different origin. This aligns with the Fetch API's redirect algorithm to prevent sensitive information from being sent to third-party origins.
Ensures explicit HTTP cache mode from incoming requests is forwarded and maintained when creating fetch requests for assets, aligning with expected fetch behavior and preventing unintended cache handling.
Preserve the redirect mode when rebuilding asset requests in newRequestWithMetadata(). This keeps explicit redirect:error semantics intact across service-worker redirect handling.
Update the worker test mocks to model redirect defaults correctly and add focused regression coverage for redirected lazy assets with redirect:error.
Adds handling and logging for unhandled promise rejections to improve debugging and prevent silent failures. Updates tests and test harness to verify logging of rejection reasons
PR Close#63059
Add client notification when an app version fails, improving error
visibility and debugging capabilities. When a version encounters a
critical error, all clients using that version are now notified
with details about the failure.
- Add notifyClientsAboutVersionFailure method call in versionFailed
- Ensure clients receive VERSION_FAILED events with error details
- Improve service worker error transparency for better debugging
PR Close#62718
In this commit, support for `notificationclose` events has been added to the service worker Driver.
When a notification is closed (either by user dismissal or programmatically), the Driver now captures the event, extracts the relevant notification options, and broadcasts a `NOTIFICATION_CLOSE` message to clients. This ensures the application is aware of notification lifecycle events and can react accordingly.
PR Close#61442
We don't need this tooling anymore because we are already validating
that there are no circular dependencies via the `ng-dev` tooling that
checks `.ts` files directly.
Also these tests never actually failed to my knowledge.
PR Close#61156
When a new version of app is available in a service worker, and a client with old version exists, web workers initialized from a client with old version will now be properly assigned with the same version.
Before this change, a web worker was assigned with the newest version.
Fixes#57971
PR Close#58131
This commit adds an `applicationMaxAge` to the service worker configuration. When set, it will only assign a cached version to clients within the `maxAge`. Afterwards, it will ignored any expired application versions and fetch exclusively from the network. The default is `undefined`, for which the behaviour is the same as it currently is.
PR Close#49601
* Updates circular dependency tests to use the `.mjs` outputs
* Switches away from CommonJS specific `require` calls.
* Simplifies the test helper logic since all browsers/NodeJS versions
support `URL` as a global.
PR Close#48521
Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would strip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed data).
This commit fixes this by preserving the headers of such requests.
For reference, Workbox passes the original request as is. (See for
example the [NetworkFirst][1] strategy).
> **Note**
> Data requests (i.e. requests for URLs that belong to a data-group) are
not affected by this. They already use the original resource as is.
[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90Fixes#24227
PR Close#47260
Previously, the `MockServerStateBuilder#withRedirect()` method did two
things: (a) define a redirect from one path to another and (b) specify
the contents of the redirect destination. This was confusing, because it
deviated from the regular way of specifying file contents, which is via
a `MockFileSystem` instance.
This commit slightly simplifies the process of defining redirects by
having the `withRedirect()` method only define the redirect and let the
contents of the redirect destination be specified as usual via
`MockFileSystem`. This makes `MockFileSystem` the single source of truth
for file contents used with `MockServerState`.
PR Close#47260
Previously, the criteria for determining if a request was a
[navigation request][1] did not account for the request method. This
incorrectly identified HTML form submit POST requests as navigation
requests and served `index.html` instead of passing them through to the
server, thus breaking the form submission.
This commit fixes this by ensuring that only GET requests are considered
navigation requests.
> **Note**
> HTML forms with their method set to `GET` will still be affected by
> the issue. This is not a big concern, because using `GET` for form
> submission is quite uncommon and generally discouraged (due to
> limitations and security considerations).
[1]: https://angular.io/guide/service-worker-config#handling-navigation-requestsFixes#36368
PR Close#47263
Implement a new `notificationclick` action, `sendRequest`, which sends a
GET request to the specified URL, without opening a new window. This can
be useful for hitting an API endpoint.
PR Close#46912
When the service worker checks for an update and finds that the version on the server is the same as
the version locally installed, it currently noops. This change introduces an event which it emits
in this situation which notifies clients a check has occurred without error and no update was found.
PR Close#45216
Add a new option for configuring data-groups, `cacheOpaqueResponses`,
that determines whether opaque responses are cached or not. This allows
greater flexibility in configuring the behavior of data-groups, while
still keeping the current defaults as fallbacks.
Fixes#44246
PR Close#44723
Make the `MockResponse` class used in tests behave more similarly to how
real responses work by making the following improvements:
- Use an empty `statusText` (`''`) when provided, instead of the default
`'OK'` value. This allows better representing opaque responses.
- Preserve more properties (`redirected`, `type`, `url`) when cloning a
`MockResponse`.
PR Close#44723
This commit introduces a new `SwUpdate#versionUpdates` observalbe, which provides more granular
information about Service Worker version updates than the already existing `SwUpdate#available`
observable.
The new events emitted by `SwUpdate#versionUpdates` basically add the possibility for application to
get notified if a new version is available on the server (not yet downloaded) and if an installation
of a new version failed.
Closes#39840
DEPRECATED: The `SwUpdate#availalbe` observable is deprecated.
The new `SwUpdate#versionUpdates` observable provides the same information and more. Therefore, it
is possible to rebuild the same behavior as `SwUpdate#availalbe` using the events emitted by
`SwUpdate#versionUpdates` and filtering for `VersionReadyEvent` events.
As a result, the `SwUpdate#availalbe` observable is now redundant.
PR Close#43668
Previously, when a version was found to be broken, any clients assigned
to that version were unassigned (and either assigned to the latest
version or to none if the latest version was the broken one). A version
could be considered broken for several reasons, but most often it is a
response for a hashed asset that eiher does not exist or contains
different content than the SW expects. See
https://github.com/angular/angular/issues/28114#issuecomment-923122967
for more details.
However, assigning a client to a different version (or the network) in
the middle of a session, turned out to be more risky than keeping it on
the same version. For angular.io, for example, it has led to #28114.
This commit avoids making things worse when identifying a broken version
by keeping existing clients to their assigned version (but ensuring that
no new clients are assigned to the broken version).
NOTE:
Reloading the page generates a new client ID, so it is like a new client
for the SW, even if the tab and URL are the same.
PR Close#43518
Previously, a ServiceWorker test was using the
`MockServerState#sawRequestFor()` method. This method, however, only
returns a boolean indicating whether a request had been seen, but would
not throw an error in either case.
Since the intention was to assert that a specific request was made, this
commit switches to the correct `MockServerState#assertSawRequestFor()`
method.
PR Close#43518
Previously, the ServiceWorker assumed that a client found in
`clientVersionMap` would exist (i.e. it could be retrieved via
`clients.get()`). However, if a browser tab had been closed, the
corresponding client (while present in `clientVersionMap`, which is only
updated on ServiceWorker initialization) would not be retrievable via
`clients.get()`.
This commit fixes it by checking whether the client exists before trying
to notify it about an unrecoverable state.
PR Close#42736
This commit better aligns the mock client implementations used in
ServiceWorker tests (and the associated typings) with the actual
implementations (and the official TypeScript typings). This allows
verifying the ServiceWorker behavior in a slightly more realistic
environment.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
In the ServiceWorker tests, we use mock implementations of the various
client APIs that the ServiceWorker interacts with. Previously, these
mock implementations were defined in the `testing/scope.ts` file. This
added several extra classes to a file that already contains a few,
making it harder to maintain.
Therefore, this commit moves these mock client classes to a separate
`testing/clients.ts` file.
PR Close#42736
This commit better aligns the mock event implementations used in
ServiceWorker tests (and the associated typings) with the actual
implementations (and the official TypeScript typings). This allows
verifying the ServiceWorker behavior in a slightly more realistic
environment.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
In the ServiceWorker tests, we use mock implementations of the various
events emitted during the ServiceWorker lifecycle. Previously, these
mock implementations were defined in the `testing/scope.ts` file. This
added several extra classes to a file that already contains a few,
making it harder to maintain.
Therefore, this commit moves these mock event classes to a separate
`testing/events.ts` file.
PR Close#42736
This commit makes the `SwTestHarness.envIsSupported()` static method a
standalone function. This function is used to determine whether the
current environment provides the necessary APIs to run the SW tests and
is independent of `SwTestHarness`, so is no need for it to be a static
method of `SwTestHarness`.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
This commit removes the duplicate `Context` interface and uses the
`ExtendableEvent` interface instead.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
Previously, the SW was only able to clean up caches for app-versions
found in the `Driver`'s `versions` map. If (for some reason) the
`Driver` failed to load a valid stored state (including app-versions)
and ended up with an [empty `versions` map][1], any obsolete versions
would remain in the cache storage. This case was rare but possible.
This commit makes the cache clean-up logic more robust by ensuring that
all app-version caches are removed unless they are currently used by the
SW to serve active clients (with the exception of the latest
app-version, which is always retained).
Fixes#41728
[1]: https://github.com/angular/angular/blob/9de65dbdceac3077881fbc49717f33d0f379e21d/packages/service-worker/worker/src/driver.ts#L515-L529
PR Close#42622
Previously, obsolete caches were only cleaned up when successfully
loading the stored state. When the state failed to be loaded, cleaning
up the caches would be skipped until the next SW initialization.
This commit changes this, ensuring that the caches are cleaned up
regardless if the stored state was loaded successfully or not.
PR Close#42622
This commit simplifies/systemizes accessing the `CacheStorage` through a
wrapper, with the following benefits:
- Ensuring a consistent cache name prefix is used for all caches
(without having to repeat the prefix in different places).
- Allowing referring to caches using their name without the common
cache name prefix.
- Exposing the cache name on cache instances, which for example makes it
easier to delete caches without having to keep track of the name used
to create them.
PR Close#42622
SkyZeroZx