angularfire: ApplicationRef.isStable never goes to "true" when an instance of AngularFireAuth is injected

When AngularFireAuth is injected anywhere on the page, the ApplicationRef.isStable never emits true. This causes problems with latest @angular/service-worker, which relies on ApplicationRef.isStable to install the worker. This probably also would cause server-side rendering to timeout, but I didn’t test this.

Version info

Angular: 5.0.0

Firebase: 4.6.2

AngularFire: 5.0.0-rc4

How to reproduce these conditions

Inject AngularFireAuth into a component and subscribe to the ApplicationRef.isStable observable:

import { Component, ApplicationRef, ChangeDetectorRef } from '@angular/core';
import { AngularFireAuth } from 'angularfire2/auth';

@Component({
  selector: 'my-app',
  templateUrl: './app.component.html',
  styleUrls: [ './app.component.css' ]
})
export class AppComponent  {
  constructor(appRef: ApplicationRef, af: AngularFireAuth) {    
    appRef.isStable.subscribe(s => {
      console.log(s); 
    });
  }
}

Here is a project that reproduces the problem: https://stackblitz.com/edit/angularfire2-appref-isstable

Expected behavior

The ApplicationRef.isStable observable should emit true shortly after application is loaded.

Actual behavior

The ApplicationRef.isStable observable emits only initial false value.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 16
Comments: 25 (10 by maintainers)

Commits related to this issue

fix: angularfire2 zona hiba miatt nem megy a cli service worker, kezzel implementalva gyors javitast helyeztunk el benne https://github.com/angular/angularfire2/issues/1347 — committed to greg-nagy/jegybazar by eggp 7 years ago

Most upvoted comments

The same issue when I injects AngularFirestore. We cannot use an @angular/service-worker as it is not registered due to this issue.

+11

deftomat on Dec 11, 2017

Any updates on this issue?

patrickmichalina on Jan 14, 2018

Fixed in rc7

jamesdaniels on May 4, 2018

This issue should be reopened. Angular9 + AngularFire6 has same issue.

JeongJun-Lee on May 20, 2020

Just talking with myself here, I managed to work around it by having to override the AngularFireAuth like this:

{ provide: AngularFireAuth, useClass: AngularFireOwnAuth },

And have this:

@Injectable()
class AngularFireOwnAuth extends AngularFireAuth {
  readonly idToken: Observable<string | null>;

  constructor(
     @Inject(FirebaseOptionsToken) options: any,
     @Optional() @Inject(FirebaseNameOrConfigToken) nameOrConfig: string|any|undefined,
     @Inject(PLATFORM_ID) platformId: Object,
     zone: NgZone
  ) {
    super(options, nameOrConfig, platformId, zone);

    this.idToken = this.user.pipe(
      switchMap(async user =>
        user ? zone.run(async() => await zone.runOutsideAngular(() => user.getIdToken())) : null
      )
    );
  }
}

This will make sure the getIdToken is called outside the angular zone. If this is called inside the zone, it will trigger the long setTimeout and prevent angular from ever getting stable. At least not for 3300000ms 😃

PierreDuc on May 31, 2018

Once patched I’ll cut a new RC.

jamesdaniels on Nov 19, 2017

I’m actually tackling right now. Thanks for the report!

jamesdaniels on Nov 19, 2017

After a little more digging I found that the problem is originating from the fireauth.AuthUser.prototype.initializeProactiveRefreshUtility_.

This is at least triggered on login with using just email and password, or by using the getIdToken() and setting forceRefresh to true.

For now the workaround is whenever you call these functions is to wrap it inside a ngZone.runOutsideAngular -> ngZone.run

PierreDuc on May 29, 2018

angularfire2 cannot leave RC stage until this is fixed.

iamart on Feb 11, 2018

I am having the same issue when injecting AngularFirestore

val-samonte on Dec 27, 2017