Bug 171770 - [GTK] Cannot sign in with new Google sign-in page
Summary: [GTK] Cannot sign in with new Google sign-in page
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P1 Critical
Assignee: Michael Catanzaro
URL:
Keywords: Gtk
: 171793 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-05-06 03:56 PDT by Jiří Janoušek
Modified: 2017-05-07 15:40 PDT (History)
7 users (show)

See Also:


Attachments
Patch (2.19 KB, patch)
2017-05-06 16:34 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiří Janoušek 2017-05-06 03:56:10 PDT
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
Comment 1 Carlos Garcia Campos 2017-05-06 04:03:14 PDT
(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
Comment 2 Michael Catanzaro 2017-05-06 06:52:05 PDT
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.
Comment 3 Michael Catanzaro 2017-05-06 06:53:12 PDT
(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.
Comment 4 Michael Catanzaro 2017-05-06 07:03:17 PDT
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.
Comment 5 Michael Catanzaro 2017-05-06 07:41:04 PDT
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.
Comment 6 Jiří Janoušek 2017-05-06 10:19:17 PDT
> 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.
Comment 7 Michael Catanzaro 2017-05-06 14:00:54 PDT
(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.
Comment 8 Michael Catanzaro 2017-05-06 16:29:21 PDT
(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.
Comment 9 Michael Catanzaro 2017-05-06 16:34:58 PDT
Created attachment 309305 [details]
Patch
Comment 10 Carlos Garcia Campos 2017-05-07 02:01:42 PDT
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
Comment 11 WebKit Commit Bot 2017-05-07 02:29:48 PDT
Comment on attachment 309305 [details]
Patch

Clearing flags on attachment: 309305

Committed r216343: <http://trac.webkit.org/changeset/216343>
Comment 12 WebKit Commit Bot 2017-05-07 02:29:50 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 Michael Catanzaro 2017-05-07 12:40:05 PDT
*** Bug 171793 has been marked as a duplicate of this bug. ***
Comment 14 Michael Catanzaro 2017-05-07 12:59:45 PDT
Committed r216350: <http://trac.webkit.org/changeset/216350>