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.
Apparently this one is bad because Whatsapp is important.
I see no errors in the web inspector, so it's definitely not related to the Promise error you see.
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
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.
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.
I can confirm this on Epiphany 3.34.1 WebKitGTK 2.26.1
also, Epiphany.Devel 3.35.2-23-g08a8f34fc with WebKitGTK 2.27.3
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.
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...
Seems to be working now.
Definitely still broken here. Given the large number of users complaining about this, let's say you're lucky and reopen?
I'm also experiencing this on Fedora 31, running 3.34.2 If i wait a few minutes the QR code then loads.
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).
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.
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
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.
(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.
Committed r255233: <https://trac.webkit.org/changeset/255233>
// 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. :)
FIY it works fine in Epiphany Nightly (flatpak version 3.35.90-12-gd41289ee1; webkit 2.27.4).