Bug 203404 – [GTK][WPE] QR code not loaded in web.whatsapp.com

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Sergio Villar Senin]

Web whatsapp app shows a QR code meant to be scanned with your phone/tablet in order to log in the service when using a desktop. The QR code is never loaded with ToT WebKitGtk.

Steps to reproduce:
1- Load web.whatsapp.com (it's important to have a closed session otherwise the page with the QR code won't be shown)

Expected result:
A QR code is shown on the top right

Actual result:
A never ending spinning animation is shown

Note that I sometimes get a Promise related error, but not definitely always.

[Michael Catanzaro]

Apparently this one is bad because Whatsapp is important.

[Michael Catanzaro]

I see no errors in the web inspector, so it's definitely not related to the Promise error you see.

[jena]

Hi there,

I have slightly different experience, as I described in this github issue:
https://github.com/artemanufrij/webpin/issues/9#issuecomment-559572869

I can load the QR code in Epiphany 3.32 (snap package on Ubuntu 18.04) while it fails in other programs (Webpin and older Epiphany 3.28 from Ubuntu repos).

WebKit versions are a bit strange:
- Ephy 3.32 (snap) has WebKit 2.24.2
- Ephy 3.28 (repo) has WebKit 2.24.4 (so it's newer, right?)

Hope it helps.

Jan

[Michael Catanzaro]

Hm, it's certainly possible that it's a regression between 2.24.2 and 2.24.4. This would be easy for a developer to confirm. Thanks.

Note: 2.24 is insecure and no longer supported. Also, beware most web process extension features are seriously broken in the snap version of Epiphany because abstract sockets are broken inside snaps for some reason.

[jena]

Funny story - I was now searching what webkit versions I have installed and which is used by Webpin and I couldn't find 2.24, only 2.26. Apparently I got some update between the github post and my comment here (the password requirements here are just nuts) so now I have 2.26.2 in the system version of Ephy (i.e. 3.28.5). The QR code still doesn't work there.

[Edoardo Vacchi]

I can confirm this on Epiphany 3.34.1
WebKitGTK 2.26.1

[Edoardo Vacchi]

also, Epiphany.Devel 3.35.2-23-g08a8f34fc
with WebKitGTK 2.27.3

[Edoardo Vacchi]

Created attachment 385156 [details]
recording of whatsapp timeline (gzipped json)

attaching trace of page loading up to a visible QR code

it's not it really doesn't load at all; it actually takes a **very** long while; on my machine >500secs. After that, the code loads instantly, it also refreshes automatically a few times, then it displays the "Click to reload QR code" button, which, when clicked, again, loads a fresh QR code instantly. 

I'd say it feels like there is some sort of timeout that triggers after 500secs (I tried a couple of times and it always seems around that mark)

hope this helps.

[Sergio Villar Senin]

Haven't double checked this but the only timeout I could think about is on the server side as a result of way too many requests from the same client but that looks like really ankward...

[Sergio Villar Senin]

Seems to be working now.

[Michael Catanzaro]

Definitely still broken here. Given the large number of users complaining about this, let's say you're lucky and reopen?

[adds68]

I'm also experiencing this on Fedora 31, running 3.34.2

If i wait a few minutes the QR code then loads.

[Carlos Garcia Campos]

A WebSocket connection is used for the QR thing. For some reason we are getting a 400 Bad Request for all our upgrade requests. When it fails, it tries again after checking there's network connection (using an XHR). After several tries it finally replies with a 101 Switching Protocols. I have no idea why it fails, because we are always sending the same request (only Sec-WebSocket-Key is different in every new request).

[Carlos Garcia Campos]

Created attachment 388865 [details]
Patch

Finally found the issue, the server replies with 400 when re-using an existing connection. We should always use a new connection for WebSockets.

[Michael Catanzaro]

Comment on attachment 388865 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=388865&action=review

> Source/WebKit/ChangeLog:10
> +        copming from an existing HTTP connection. We need to ensure a new dedicated connection is used for WebSockets.

coming

[Sergio Villar Senin]

I'd add some reference to the WS RFC, https://tools.ietf.org/html/rfc6455 in particular to this paragraph:

   When the client is to _Establish a WebSocket Connection_ given a set
   of (/host/, /port/, /resource name/, and /secure/ flag), along with a
   list of /protocols/ and /extensions/ to be used, and an /origin/ in
   the case of web browsers, it MUST open a connection, send an opening
   handshake, and read the server's handshake in response.

[Carlos Garcia Campos]

(In reply to Sergio Villar Senin from comment #16)
> I'd add some reference to the WS RFC, https://tools.ietf.org/html/rfc6455 in
> particular to this paragraph:
> 
>    When the client is to _Establish a WebSocket Connection_ given a set
>    of (/host/, /port/, /resource name/, and /secure/ flag), along with a
>    list of /protocols/ and /extensions/ to be used, and an /origin/ in
>    the case of web browsers, it MUST open a connection, send an opening
>    handshake, and read the server's handshake in response.

That's a good point, but also makes me think we should fix this in libsoup, because the spec is implemented by libsoup. We still need this patch in WebKit until we bump the libsoup requirements, so I'll add a FIXME comment instead.

[Carlos Garcia Campos]

Committed r255233: <https://trac.webkit.org/changeset/255233>

[Michael Catanzaro]

// FIXME: this is done by libsoup since 2.69.1 and 2.68.4, so it can be removed when bumping the libsoup requirement.

Problem is we won't find that FIXME comment when actually bumping the libsoup requirement. If you also add:

#if !SOUP_CHECK_VERSION(2, 70, 0)
    soup_message_set_flags(msg, static_cast<SoupMessageFlags>(soup_message_get_flags(msg) | SOUP_MESSAGE_NEW_CONNECTION));
#endif

Then anyone grepping for SOUP_CHECK_VERSION is guaranteed to find it. :)

[jena]

FIY it works fine in Epiphany Nightly (flatpak version 3.35.90-12-gd41289ee1; webkit 2.27.4).

[Haider Salman]

as of today the issue has returned in epiphany nightly installed through flatpak

[Philippe Normand]

This started happening again, reopening.

[Philippe Normand]

[Error] Unhandled Promise Rejection: DataCloneError: The object can not be cloned.
 DataCloneError: The object can not be cloned.

In JS console. Not sure if relevant.

[Michael Catanzaro]

I suggest creating a new bug report for this, since the underlying cause is going to be different even though the symptoms are the same.

Also, please check if 2.44 is affected.

[Haider Salman]

new bug report there sry if its not that good im new to this 

https://bugs.webkit.org/show_bug.cgi?id=275890

Web whatsapp is not loading 
I waited 1h but QR code did not Load at all.

[Michael Catanzaro]

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