Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[firebase_auth_web]: authStateChanges() never emits in --profile web builds (listener key 'no-op' collides)

Open
  • Is something wrong?
#18,728 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
dart
Domain
authentication, web-dev

Research direction

Start with packages/firebase_auth/firebase_auth_web/lib/src/interop/auth.dart and packages/firebase_core/firebase_core_web/lib/src/interop/utils/utils.dart, focusing on _authStateWindowsKey(), _idTokenStateWindowsKey(), and the listener storage methods. Reproduce with a Flutter web app using flutter build web --profile and multiple auth streams. Done means authStateChanges() emits its initial state in profile builds without cancelling another listener, while debug and release behavior remains intact.

Written by the indexing model from the issue text.

Description

Is there an existing issue for this?
  • I have searched the existing issues.
Which plugins are affected?

Auth, Core

Which platforms are affected?

Web

Description

In a flutter build web --profile build, FirebaseAuth.instance.authStateChanges() never emits. An app that waits for the first auth event (for example a router redirect that holds a splash screen until auth state is known) hangs forever. Debug and release builds work.

The JS SDK itself is fine. In the same page, onAuthStateChanged called directly through the JS SDK fires immediately with null.

Cause. The two packages disagree about what "debug" means:

  • firebase_auth_web builds the hot-restart listener key only under Flutter's kDebugMode. kDebugMode is false in profile, so every listener gets the same key, 'no-op':
    packages/firebase_auth/firebase_auth_web/lib/src/interop/auth.dart, _authStateWindowsKey() / _idTokenStateWindowsKey(): 
    if (kDebugMode) { ... return '$key-${_authStateListeners[key]}'; }
return 'no-op';
  • firebase_core_web stores and cancels those listeners under its own flag, which is true in profile:
    packages/firebase_core/firebase_core_web/lib/src/interop/utils/utils.dart: 
    const bool _kDebugMode = !bool.fromEnvironment('dart.vm.product');
    setWindowsListener / unsubscribeWindowsListener / removeWindowsListener are all gated on it.

So in profile, onAuthStateChanged / onIdTokenChanged store their JS unsubscribe function at window['no-op']. The next getter call runs unsubscribeWindowsListener('no-op'), which calls that stored function and cancels the previous subscription's JS listener. The Dart StreamController stays open but never receives an event. The event it seeded with _changeController!.add(_initUser) was added before any listener existed, so the broadcast controller dropped it.

In release both flags are false, and in debug both are true with unique keys, which is why only profile is affected.

The code is unchanged on main as of today.

Suggested fix: use the same condition in both places. For example, have firebase_core_web use kDebugMode from package:flutter/foundation.dart, or make _authStateWindowsKey() / _idTokenStateWindowsKey() always return a unique key.

Reproducing the issue
  1. Take any web app that listens to FirebaseAuth.instance.authStateChanges() and also triggers a second auth stream (idTokenChanges(), userChanges(), or a second authStateChanges() call).
  2. flutter build web --profile and serve build/web.
  3. Open it signed out. The authStateChanges() listener never fires. With flutter run -d chrome or flutter build web --release, it fires null straight away.

To confirm it is the listener being cancelled, put prints in the stream: the provider builds and the redirect runs with the state still loading, but no event ever arrives. In the same page, firebase_auth.onAuthStateChanged(getAuth(app), cb) from the JS SDK fires at once.

Firebase Core version

4.15.0 (firebase_core_web 3.12.0)

Flutter Version

3.47.2

Relevant Log Output
No error is logged. The auth stream is silently cancelled.
Flutter dependencies
firebase_core: 4.15.0
firebase_core_web: 3.12.0
firebase_auth: 6.7.0
firebase_auth_web: 6.3.0
Additional context and comments

Found while profiling a production app. The fix above is based on reading the source, and the diagnosis was confirmed with print statements in a profile build. I have not built a standalone minimal repro project.

Dominant language
Dart
Stars
9.3k
Forks
4.1k
Avg merge
2d 2h
Merged PRs (30d)
34

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from firebase/flutterfire

All issues in firebase/flutterfire

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.