Bug 171770 – [GTK] Cannot sign in with new Google sign-in page

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Jiří Janoušek]

Hello. I cannot sign-in to Google services since it introduced a new sign-in page.

Steps to reproduce:

1. Open a WebKitGTK browser.
2. Visit https://google.com
3. Click sign-in button in the top right corner.
4. Type e-mail and click Next.
5. Enter password and click Next.

Expected result:

- Google asks for a pin from two-factor authentication. (It does so in Firefox 52 and Chromium 58.)

Actual result:

- An empty page is loaded (https://accounts.google.com/signin/v2/challenge/password/empty).
- There is no error in the JavaScript console.

Clients:

Epiphany 3.22.6, WebKitGTK+ 2.14.6
MiniBrowser, WebKitGTK+ 2.16.1

[Carlos Garcia Campos]

(In reply to Jiří Janoušek from comment #0)
> Hello. I cannot sign-in to Google services since it introduced a new sign-in
> page.
> 
> Steps to reproduce:
> 
> 1. Open a WebKitGTK browser.
> 2. Visit https://google.com
> 3. Click sign-in button in the top right corner.
> 4. Type e-mail and click Next.
> 5. Enter password and click Next.
> 
> Expected result:
> 
> - Google asks for a pin from two-factor authentication. (It does so in
> Firefox 52 and Chromium 58.)
> 
> Actual result:
> 
> - An empty page is loaded
> (https://accounts.google.com/signin/v2/challenge/password/empty).
> - There is no error in the JavaScript console.
> 
> Clients:
> 
> Epiphany 3.22.6, WebKitGTK+ 2.14.6
> MiniBrowser, WebKitGTK+ 2.16.1

Empty page with current trunk too

[Michael Catanzaro]

OK, I can reproduce. Problem is the server is sending us a completely blank. So... I don't even know where to start trying to debug this. Historically, we have had zero luck trying to get Google to fix any of their many bugs affecting WebKit, so this is going to be a big problem.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #2)
> OK, I can reproduce. Problem is the server is sending us a completely blank.

a completely blank page. Not even HTML body tags or even a single character.

[Michael Catanzaro]

The Firefox UA quirk breaks the login page.

This is unmanageable. I'm at wits end. We are going to have to base our Google user agent quirks on the path component of the URI.

I'm really at a loss for words as to how horrible this is.

[Michael Catanzaro]

You know, if we're very lucky, we *might* be able to get away with doing this:

static bool urlRequiresFirefoxBrowser(const URL& url)
{
    return isGoogle(url) && url.host() != "accounts.google.com";
}

That's probably not very likely to work, but if it works, then we're saved. At any rate, just removing the Firefox quirk and leaving Calendar and Maps/Earth broken is not acceptable.

[Jiří Janoušek]

> a completely blank page. Not even HTML body tags or even a single character.

Looking at Firefox's web inspector, Google sends the same to Firefox too, but then there is XHR POST request to https://accounts.google.com/signin/v2/challenge/totp and this is URL eventually appears in the URL bar. No idea how, it's just magic.

> The Firefox UA quirk breaks the login page.

Indeed, I've set "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/604.1 (KHTML, like Gecko) Version/11.0 Safari/604.1" as the user agent string in my Nuvola app for Google Play Music and it works. Does WebKitSettings:enable_site_specific_quirks affect anything else than an user agent string?

Is there any public API to set a different user agent per request? It would be convenient if I could modify user agent quirks without a need to wait for a next WebKitGTK release.

[Michael Catanzaro]

(In reply to Jiří Janoušek from comment #6)
> Does
> WebKitSettings:enable_site_specific_quirks affect anything else than an user
> agent string?

Yes, turning that off is going to break other websites. I'm not sure off the top of my head which, but I think there are maybe layout or some other sort of quirks for YouTube.

> Is there any public API to set a different user agent per request? It would
> be convenient if I could modify user agent quirks without a need to wait for
> a next WebKitGTK release.

No, sorry, the only way is to disable site specific quirks. We will make a release ASAP, since this is an emergency.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #5)
> You know, if we're very lucky, we *might* be able to get away with doing
> this:

It works, rejoice.

[Michael Catanzaro]

Created attachment 309305 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 309305 [details]
Patch

I'm r+ and cq+'ing because this is important fix, but it should include a unit tests, please add it in a follow up patch. Thanks for fixing this mess

[WebKit Commit Bot]

Comment on attachment 309305 [details]
Patch

Clearing flags on attachment: 309305

Committed r216343: <http://trac.webkit.org/changeset/216343>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Michael Catanzaro]

*** Bug 171793 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

Committed r216350: <http://trac.webkit.org/changeset/216350>