Commit Graph

11 Commits

Author SHA1 Message Date
Hoel IRIS 21bc16d4d8 fix(service-worker): handle error with console.error (#40236)
This commit reverts commit [_fix(service-worker): handle error with
ErrorHandler_](https://github.com/angular/angular/pull/39990/commits/552419d).

With Angular v11.0.4 and commit [_fix(service-worker): handle error with
ErrorHandler_](https://github.com/angular/angular/pull/39990/commits/552419d)
Angular start to send all service worker registration errors to the Angular
standard `ErrorHandler#handleError()` interface, instead of logging them in the
console.
But users existing `ErrorHandler#handleError()` implementations are not adapted
to service worker registration errors and it might result in broken apps or
bad UI.
Passing to `ErrorHandler` is desirable for some and undesirable for others and
the same is true for passing to `console.error()`.
But `console.error()` was used for a long time and thus it is preferable to keep
it as long as a good solution is not found with `ErrorHandler`.

Right now it's hard to define a good solution for `ErrorHandler` because:

1. Given the nature of the SW registration errors (usually outside the control
   of the developer, different error messages on each browser/version, often
   quite generic error messages, etc.), passing them to the `ErrorHandler` is
   not particularly helpful.
2. While `ErrorHandler#handleError()` accepts an argument of type `any` (so
   theoretically we could pass any object without changing the public API), most
   apps expect an `Error` instance, so many apps could break if we changed the
   shape.
3. Ideally, the Angular community want to re-think the `ErrorHandler` API
   and add support for being able to pass additional metadata for each error
   (such as the source of the error or some identifier, etc.). This change,
   however, could potentially affect many apps out there, so the community must
   put some thought into it and design it in a way that accounts for the needs
   of all packages (not just the SW).
4. Given that we want to more holistically revisit the `ErrorHandler` API, any
   changes we make in the short term to address the issue just for the SW will
   make it more difficult/breaky for people to move to a new API in the future.

To see the whole explanation see GitHub PR #40236.

PR Close #40236
2021-01-25 10:11:58 -08:00
Christoph Guttandin 74e42cf7d5 fix(service-worker): handle error with ErrorHandler (#39990)
Errors thrown by calling serviceWorker.register() are now passed to the global ErrorHandler.

Fixes #39913

PR Close #39990
2020-12-08 12:03:27 -08:00
Joey Perrott d1ea1f4c7f build: update license headers to reference Google LLC (#37205)
Update the license headers throughout the repository to reference Google LLC
rather than Google Inc, for the required license headers.

PR Close #37205
2020-05-26 14:26:58 -04:00
JiaLiPassion 41667de778 fix(zone.js): add issue numbers of `@types/jasmine` to the test cases (#34625)
Some cases will still need to use `spy as any` cast, because `@types/jasmine` have some issues,
1. The issue jasmine doesn't handle optional method properties, https://github.com/DefinitelyTyped/DefinitelyTyped/issues/43486
2. The issue jasmine doesn't handle overload method correctly, https://github.com/DefinitelyTyped/DefinitelyTyped/issues/42455

PR Close #34625
2020-04-08 12:10:34 -07:00
JiaLiPassion ef4736d052 build: update jasmine to 3.5 (#34625)
1. update jasmine to 3.5
2. update @types/jasmine to 3.5
3. update @types/jasminewd2 to 2.0.8

Also fix several cases, the new jasmine 3 will help to create test cases correctly,
such as in the `jasmine 2.x` version, the following case will pass

```
expect(1 == 2);
```

But in jsamine 3, the case will need to be

```
expect(1 == 2).toBeTrue();
```

PR Close #34625
2020-04-08 12:10:34 -07:00
Sonu Kapoor 29e8a64cf0 fix(service-worker): by default register the SW after 30s even the app never stabilizes (#35870)
Previously, when using the default ServiceWorker registration strategy
Angular would wait indefinitely for the [app to stabilize][1], before
registering the ServiceWorker script. This could lead to a situation
where the ServiceWorker would never be registered when there was a
long-running task (such as an interval or recurring timeout).

Such tasks can often be started by a 3rd-party dependency (beyond the
developer's control or even without them realizing). In addition, this
situation is particularly hard to detect, because the ServiceWorker is
typically not used during development and on production builds a
previous ServiceWorker instance might be already active.

This commit fixes this by changing the default registration strategy
from `registerWhenStable` to `registerWhenStable:30000`, which will
ensure that the ServiceWorker will be registered after 30s at the
latest, even if the app has not stabilized by then.

Fixes #34464

PR Close #35870
2020-03-27 10:47:44 -07:00
Sonu Kapoor 00efacf561 feat(service-worker): support timeout in `registerWhenStable` SW registration strategy (#35870)
Previously, when using the `registerWhenStable` ServiceWorker
registration strategy (which is also the default) Angular would wait
indefinitely for the [app to stabilize][1], before registering the
ServiceWorker script. This could lead to a situation where the
ServiceWorker would never be registered when there was a long-running
task (such as an interval or recurring timeout).

Such tasks can often be started by a 3rd-party dependency (beyond the
developer's control or even without them realizing). In addition, this
situation is particularly hard to detect, because the ServiceWorker is
typically not used during development and on production builds a
previous ServiceWorker instance might be already active.

This commit enhances the `registerWhenStable` registration strategy by
adding support for an optional `<timeout>` argument, which guarantees
that the ServiceWorker will be registered when the timeout expires, even
if the app has not stabilized yet.

For example, with `registerWhenStable:5000` the ServiceWorker will be
registered as soon as the app stabilizes or after 5 seconds if the app
has not stabilized by then.

Related to #34464.

[1]: https://angular.io/api/core/ApplicationRef#is-stable-examples

PR Close #35870
2020-03-27 10:47:44 -07:00
Carlos Ortiz García 9166baf709 refactor(core): Migrate TestBed.get to TestBed.inject (#32382)
This is cleanup/followup for PR #32200

PR Close #32382
2019-09-09 19:10:54 -04:00
Hoel IRIS 81c2a94310 fix(service-worker): avoid uncaught rejection warning when registration fails (#30876)
Service worker API `navigator.serviceWorker.register` can fail in multiple ways.
For example, in Chrome, with an unstable network connection you can have the
following error: `An unknown error occurred when fetching the script.`

In the current state, it creates an `Uncaught (in promise) TypeError:` style of
error, which cannot be caught by the user on his own.

I think it's better to log the error over raising an error that cannot be
caught.

PR Close #30876
2019-06-07 08:46:25 -07:00
George Kalpakas 957f594d7c test(service-worker): add tests for `RegistrationOptions#registrationStrategy` (#21842)
PR Close #21842
2019-04-25 12:29:59 -07:00
George Kalpakas be28a6ad8e test(service-worker): expand `SwRegistrationOptions` tests and move to separate file (#21842)
PR Close #21842
2019-04-25 12:29:58 -07:00