@alxhub Hello, do you have any ETA on this bug?

I'm also curious to know why using a setInterval could cause this issue. You may also look at the setTimeout function.

I have another project which has the a similar problem but does not use any setInterval as far as I know (maybe in the dependencies though). So it may be a wider problem.

Hello @Ploppy3,

There is an ongoing investigation into this issue (which affects far more than service worker - the Angular zone never becomes stable in such an app).

I run into the same problem when I use interval from
import { interval } from 'rxjs/observable/interval';
like in the service worker docs.

As a workaround I did that

this.ngZone.runOutsideAngular(() => {
  interval(ms).subscribe(() => {
    this.ngZone.run(() => this.updates.checkForUpdate());
  });
});

and everything works fine now, but this is just a workaround.

By the way, awesome service worker integration, big thx for that!

@skydever I implemented this already but with the regular setInterval function.

@Ploppy3 ok, good to know

seems to be related to #8089, so I am not sure if it really is just a workaround @alxhub ?

I have been fighting this issue for ~3 months as well. My NGSW never registers and it has been almost impossible to debug.

The information here is very helpful though. I run FullStory on my site and it is extremely important to keep in place. However, it does send a POST request every few seconds. You can observe this on https://www.marketamplified.com/ using Chrome's Network tab. This would very much explain the issue that I am seeing where the NGSW never gets registered, no matter what.

I'm working on verifying this atm. I also use Firebase Auth and Firebase DB, so those may also do something to keep the page from being 'stable'.

OK, I just verified that I had to disable both Firebase and Fullstory to get NGSW to register. After all of these months, just seeing it register finally was a great feeling! My app doesn't render on the page, but I have a SW! 😉

Of course, I can't just pull Firebase and Fullstory from my app in order to use NGSW. I also don't think that I want to run all of AngularFire2 and Firebase outside of Angular.

Is there a param that I can sent to override this behavior and force registration?

As a workaround, I was able to modify some of the files in node_modules/@angular/service-worker to just do:
return navigator.serviceWorker.register(script, { scope: options.scope });

Then I was able to get my app working in addition to NGSW registered.

It would be nice to add a RegistrationOptions field that allowed indicating the max time for the NGSW to wait for registration.

@alxhub I've created a reproduction repo here. You can see that the NGSW doesn't register here.

@Ploppy3 , could you create a reproduce repo? I would like to debug the zone related part.

@JiaLiPassion is it what you ask for? https://github.com/Ploppy3/zone-debug-service-worker

@Ploppy3 , thank you, I think I may have found the reason, I will try to check it further and create a PR in zone.js.

@Ploppy3 , I have created a PR, angular/zone.js#999, I used you repo to test, it worked.

@Splaktar , could you try the attached zone.js.zip to test your repo? I used your repo and some google api error occurs.
zone.js.zip

@JiaLiPassion Did you try with setTimeout? It may be a problem too, I did not test though.

@Ploppy3 , I will test it, but setTimeout is different with setInterval, I think it should be ok.

update

I tested with you repo, setTimeout is ok.
The reason setInterval is not stable because zone.js will update internal task count when schedule, but will never decrease it.

Ok thank you very much, do you think this will result in any performance gain ?

@Ploppy3, I believe performance will be the same with current version.
except in some rare case, which is there are lot of setInterval and cancelInterval calls in the logic. in such kind of case, there will be performance improvement because in the new PR, setInterval will not trigger onHasTask any more.

Ran into this issue on a new Angular 6.1.4 app. Service Worker doesn't install when rxjs' interval is used as advised in the official documentation. When it's commented out, everything works as expected.

Is there any sign of an official workaround/fix for this issue? It seems odd to me that the docs would recommend this approach if it doesn't work. It seems like there should be some kind of note in the docs that warns about this behavior.

This is sooooo ugly. Just spent two hours to find out that the documentation is recommending the not-working "solution".

I'm fine with running things outside angular zone, I don't even care whether this is a workaround or not. But, for the god's sake, I ask for all the people who will come to this issue some day, fix the documentation!

Better it recommends nothing than something that is known to be not working since already half a year.

@smnbbrv You can open an issue regarding the documentation.

Also, only the setTimeout or setInterval statements should run outside the zone, the given function should run in the zone and therefore it does not affect your app.

this.ngZone.runOutsideAngular(() => {
  interval(1000).subscribe(() => {
    this.ngZone.run(() => {
      // put your usual code here
    });
  });
});

With code comes from angular-cli#8779, also works. That's, wrap the interval part after the application is stable. thanks @dirand

export class AppComponent implements OnInit {
  title = 'app';

  constructor(private applicationRef: ApplicationRef) {
  }

  ngOnInit() {

    this.applicationRef.isStable.subscribe((s) => { // #1
      if (s) { // #2
        setInterval(t => { console.log('Ping')}, 500);
      } // #3
    }); // #4
    // If you uncomment 1-4 - service-worker will not run

    this.applicationRef.isStable.subscribe(t => {
      console.log('App stable: ' + t);
    });
  }
}

Should it be possible to throw a error when the application does not reach a stable state within x seconds after calling ServiceWorkerModule.register()?

I think that would help a lot of users having this problem.

Once #21842 lands, we could consider changing the default strategy to registering once stable or when a certain amont of time passes (whichever comes first).

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}