Why does it work on localhost?

In our experience the local server sends no security headers, and local code often runs faster, so the popup opens inside the click’s window. The live site can add a Cross-Origin-Opener-Policy header or extra loading before sign-in.

Should I switch to signInWithRedirect?

It avoids popup blockers, and Firebase prefers it on mobile. Follow Firebase’s redirect best practices first, since redirect sign-in in browsers that block third-party storage needs one of the setup options Firebase lists.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

Firebase Google Sign-In Popup Blocked? Fix

Firebase Auth errorFirebase Google sign-in fails with “auth/popup-blocked” on the live site

The Sign in with Google button works on your machine, and on the live site it fails with auth/popup-blocked, or the popup opens and the app reports auth/popup-closed-by-user. The browser decides whether a popup may open and talk back to your page. Here’s what it checks, in the browser docs’ and Firebase’s words, and the fix.

Short answer

Browsers only allow a popup that opens right after a click. If your code awaits something (loading config, a network call) before signInWithPopup, the click may no longer count, and the browser can block the popup. Call signInWithPopup first thing in the click handler, or use signInWithRedirect, following Firebase’s redirect best practices.

Why the popup fails, and the fix

01
Work runs before signInWithPopup
“Popup windows must be opened in direct response to user input, and a separate user gesture event is required for each Window.open() call.” MDN, Window.open()
A click gives the page a short window in which it may open a popup. Awaiting anything first, such as fetching settings or checking a database, can use up that window, so the browser blocks the popup. Do that work before the click, and make signInWithPopup the first call in the handler.
02
A security header cuts the popup off from your page
“It also means that any object opened by your document in a new BCG can't access it using window.opener.” MDN, Cross-Origin-Opener-Policy
Some security templates add Cross-Origin-Opener-Policy: same-origin. With it, a page your app opens from another origin can’t reach your page through window.opener. Neither MDN nor Firebase links this header to Firebase errors, so this is our own check: when the popup opens but the app reports popup-closed-by-user, we look for this header and try same-origin-allow-popups. popup-closed-by-user can also simply mean the person closed the window.
03
Mobile browsers: Firebase prefers redirect
“The redirect method is preferred on mobile devices.” Firebase, Authenticate using Google with JavaScript
Firebase prefers redirect on mobile. Redirect has its own catch: browsers that block third-party storage break it unless you apply one of the setup options on Firebase’s redirect best practices page. For apps not hosted on Firebase, one of those options is to go back to signInWithPopup().

Checked against the vendor’s docs on November 1, 2026: MDN: Window.open(); MDN: Transient activation; MDN: Cross-Origin-Opener-Policy; Firebase docs: Authenticate using Google with JavaScript; Firebase docs: Best practices for signInWithRedirect.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Why the popup fails, and the fix

Work runs before signInWithPopup

A security header cuts the popup off from your page

Mobile browsers: Firebase prefers redirect

Rather hand it over?

More on this error

Describe it and get a written quote