Google Sign-In API Hang with uncaught error Failed to get parent origin from URL hash

Question

I'm using Google Sign-In JavaScript client for months without problem. But recently when user tapping on sign in button from webapp that added to homescreen, the signin pop-up just hang without showing any content.

When debugged via remote debugging, an error is displayed in console pane:

Uncaught Failed to get parent origin from URL hash!

originated from 4188232449-v2-idpiframe.js:136 (javascript loaded internally by google library).

I'm sure it's not programming/config error since the same webapp was previously working for months without problem, and I haven't modified any code.

I've tried google search for this particular problem and browse Google documentation for any recent changes in Google Sign-In API without any luck.

Is it bug from Google API Javascript client library, glitch from recent Chrome browser update on Android, or there is some changes in API usage that I doesn't yet aware?

Library used is https://apis.google.com/js/platform.js

This is init param for gapi.auth2.init():

{
  client_id: GAPI_CID,  // defined as constant
  cookiepolicy: 'single_host_origin',
  prompt: 'select_account',
  ux_mode: 'popup',
  fetch_basic_profile: true
}

Any insight will be much appreciated. Thank you.

P.S.: This problem is different with Uncaught Failed to get parent origin from URL hash since on that case the problem is caused by misconfiguration of required credential in Google API console. If you never had succedded in integrating sign-in flow with your app, perhaps answer from that post can help you.

Otherwise, if you have had successfully integrated sign-in flow for some time but recently problem suddenly/erratically appears with symptom of blank screen on popped-up window, than you have same problem with me.

Answer 1

I can confirm we are experiencing the same problems at my company since recently. It seems a bit erratic, not 100% of the time. But for some users, some time, they are met with an empty sign-in popup with the url pointing to "https://accounts.google.com/o/oauth2/iframe" but nothing happens.

Answer 2

Not a complete answer yet, but this may be a reasonable workaround for some. I updated the ux_mode to use redirect and it is partially working now.

auth2 = gapi.auth2.init({
    client_id: '1234.apps.googleusercontent.com',
    scope: 'profile email',
    ux_mode: 'redirect',
    redirect_uri: 'https://blahblah.io/oauth2callback'
})

NOTE: it seems redirect_uri is required, contrary to Google's docs. This isn't a perfect drop-in replacement, but it solves the "URL hash!" error

This blog post and the Git Repo in it could also be helpful for anyone attempting to use redirect

Answer 3

My electron app started to fail today for the same reason. Been debugging quite a lot and I think found the reason, but don't know how to solve it, why it happened, or if it is electron or google's fault.

In my electron app, I have 2 webviews, one for the main content and another one for google popup dialogs.

So when google needs to open the authentication, it generates this IFRAME:

    <iframe id="ssIFrame_google" 
                sandbox="allow-scripts allow-same-origin" aria-hidden="true" 
                src="https://accounts.google.com/o/oauth2/iframe#origin=https%3A%2F%2Fxxxx.com&amp;rpcToken=dxxd318480305.4777704" 
                style="... display: none;"></iframe>

Mind that the URL has HASH parameters: your origin and the token.

However, when on the electron side I capture the new-window event in order to open the URL myself in another webview, the event I receive LACKS the hash parameters:

event { 
  type : "new-window",
  url:"https://accounts.google.com/o/oauth2/iframe",
  .
  .
}

So what google's iframe is complaining about (I debugged it) is exactly that it can't find the origin and rpctoken parameters that should be in the hash parameters.

For a reason I don't understand (I haven't updated electron) the new-window event does not receive the full url anymore.

Using @howMuchCheeseIsTooMuchCheese answer below I have changed the flow to use the redirect callback, then capture that callback myself and restart the application. It is not ideal, but at least I can login into my applications.