Firebase sign-in fails in Firefox and Safari: "missing initial state" and blocked popups

What each browser does to the Firebase sign-in helper

Firebase's redirect flow loads helper code from your authDomain (<project>.firebaseapp.com by default) in a cross-origin iframe. When the user comes back, that helper needs to read storage it wrote earlier. Firebase states the mechanism "doesn't work with browsers that block third-party storage access." If the browser hands the helper a different, partitioned storage bucket, the handler reports: "Unable to process request due to missing initial state. This may happen if browser sessionStorage is inaccessible or accidentally cleared."

So this is not a Firefox or Safari bug to wait out. All three browsers isolate the helper's storage; the fix belongs in your app's setup.

Step 1: Confirm it's a storage-partitioning problem

1. Compare two hostnames: the one in your address bar and the authDomain in your Firebase config. If they are different sites (for example app.example.com and my-project.firebaseapp.com), you are affected. Firebase says apps served from their own firebaseapp.com subdomain on Firebase Hosting are not affected.
2. Open DevTools > Network, start sign-in, and look at the /__/auth/iframe and /__/auth/handler requests. If their host differs from your app's site, the helper is running as a third party.
3. Reproduce in a Firefox private window and in Safari. If sign-in also fails the same way on firebaseapp.com itself, the cause is elsewhere; see signInWithRedirect not working.

Don't ask users to switch off tracking protection. Firebase says asking users to disable storage partitioning "is rarely an option," and MDN warns that Firefox's temporary storage-access heuristics, which can make the flow work for some users some of the time, "should not be relied upon."

Step 2: Apply one of Firebase's five fixes

Option 1: Use your Firebase Hosting domain as authDomain

Change only authDomain; Firebase says not to modify other config fields.

import { initializeApp } from "firebase/app";

const firebaseConfig = {
  apiKey: "<api-key>",
  authDomain: "app.example.com", // the domain that serves your app
  projectId: "<project-id>",
  appId: "<app-id>",
};
export const app = initializeApp(firebaseConfig);

Then (console steps as of Oct 2026):

1. Add https://app.example.com/__/auth/handler to your Google OAuth client's Authorized redirect URIs. The trailing /__/auth/handler is required.
2. Make sure the domain is listed under Security > Authentication > Settings > Authorized domains in the Firebase console (older guides: Build > Authentication > Settings).
3. Redeploy on Firebase Hosting so /__/firebase/init.json is current.

Option 2: Switch to signInWithPopup

import { getAuth, GoogleAuthProvider, signInWithPopup } from "firebase/auth";

const auth = getAuth(app);
const userCred = await signInWithPopup(auth, new GoogleAuthProvider());

Remove the getRedirectResult step. Firebase notes popups can be blocked and are less smooth on mobile; see the Safari section below.

Option 3: Reverse-proxy /__/auth/ to firebaseapp.com

Forward GET and POST requests for https://app.example.com/__/auth/ to https://<project>.firebaseapp.com/__/auth/. It must be transparent to the browser; a 302 redirect will not work. Firebase's nginx example:

# reverse proxy for signin-helpers for popup/redirect sign in.
location /__/auth {
  proxy_pass https://<project>.firebaseapp.com;
}

Then do the three Option 1 steps (authDomain, redirect URI, authorized domain). Platform-specific proxy setups are in How to change your Firebase authDomain.

Option 4: Self-host the sign-in helper files

Download these from <project>.firebaseapp.com and serve them from your domain at the same paths: __/auth/handler, __/auth/handler.js, __/auth/experiments.js, __/auth/iframe, __/auth/iframe.js, __/auth/links, __/auth/links.js and __/firebase/init.json. Re-sync them periodically to pick up fixes, then do the Option 1 steps. Firebase says this option does not work for Apple sign-in or SAML.

Option 5: Sign in with Google yourself, then hand the credential to Firebase

Firebase's own Option 5 sample uses the older gapi.auth2 library. The same idea with the Google Identity Services library looks like this:

<script src="https://accounts.google.com/gsi/client" async></script>
<div id="google-btn"></div>

import { getAuth, GoogleAuthProvider, signInWithCredential } from "firebase/auth";

const auth = getAuth(app);

window.onload = () => {
  google.accounts.id.initialize({
    client_id: "<your-web-client-id>.apps.googleusercontent.com",
    callback: async (response) => {
      // response.credential is the Google ID token (a JWT)
      const credential = GoogleAuthProvider.credential(response.credential);
      await signInWithCredential(auth, credential);
    },
  });
  google.accounts.id.renderButton(document.getElementById("google-btn"), {
    theme: "outline",
    size: "large",
  });
};

Add your site (scheme and hostname only) to that client's Authorized JavaScript origins; for local work add both http://localhost and http://localhost:<port>.

Test this on a preview deployment before relying on it.

Safari says auth/popup-blocked

If you chose Option 2 and Safari users get auth/popup-blocked, a common cause is a popup opened outside a direct user gesture. MDN: popups "must be opened in direct response to user input," and that permission (transient activation) expires and is consumed by window.open(). Safari also has a user-level Block Pop-ups setting.

Fix it in code first:

1. Import and initialize firebase/auth when the page loads, not inside the click handler.
2. Make signInWithPopup the first awaited call in the click handler. No fetch, dynamic import() or other await before it.
3. Fall back to a redirect only once Option 1, 3 or 4 is in place, or the redirect will hit "missing initial state" instead.

import { getAuth, GoogleAuthProvider, signInWithPopup, signInWithRedirect } from "firebase/auth";

const auth = getAuth(app);
const provider = new GoogleAuthProvider();

document.getElementById("google-signin").addEventListener("click", async () => {
  try {
    await signInWithPopup(auth, provider); // first await in the handler
  } catch (err) {
    if (err.code === "auth/popup-blocked") {
      await signInWithRedirect(auth, provider); // needs Option 1, 3 or 4
    } else {
      throw err;
    }
  }
});

If a user has blocked pop-ups themselves, Apple documents the switches: on iPhone or iPad, Settings > Apps > Safari > Block Pop-ups; on Mac, Safari > Settings > Websites > Pop-up Windows, then choose Allow for your site. Mozilla says Firefox blocks pop-ups by default, but events such as a click or key press can still open them; users can add an exception from Settings > Privacy & Security, using the Exceptions button next to the pop-up blocking option in the Permissions section. More on this error: auth/popup-blocked.

How to confirm it worked

• In a Firefox private window and in Safari, complete a redirect sign-in. getRedirectResult(auth) should return a user, and auth.currentUser should be set after reload.
• With Options 1, 3 or 4, DevTools > Network should show /__/auth/handler on your own domain.
• With Option 2, click the button once in Safari: the Google window should open with no blocked-popup icon in the address bar.

Related problems

• Choosing between the two flows: Popup or redirect?
• What the error text means in plain terms: Missing initial state, explained