Bug 183163 - [SOUP] WebKitGTK randomly hangs while using a http proxy
Summary: [SOUP] WebKitGTK randomly hangs while using a http proxy
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-27 06:35 PST by Cédric Bellegarde
Modified: 2021-12-14 17:26 PST (History)
7 users (show)

See Also:


Attachments
Running youtube.com/tv on MiniBrowser/WebKitGTK-2.22.3 with http_proxy (237.56 KB, image/png)
2018-11-12 05:37 PST, Aleksei Lazarev
no flags Details
Postern appearing in a minute on MiniBrowser with http_proxy (650.98 KB, image/png)
2018-11-12 05:38 PST, Aleksei Lazarev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Bellegarde 2018-02-27 06:35:18 PST
Tested with multiple proxy servers: Squid, Tinyproxy, ...

Randomly, while WebKitGTK is loading a page, it goes through WebKit2.LoadEvent.STARTED, WebKit2.LoadEvent.COMMITED but never reaches WebKit2.LoadEvent.FINISED.

Happens with Eolie and Epiphany.

Looking at network inspector, seems WebKitGTK is hanging on some ressource loading (right clicking on a locked ressource and open in new tab from inspector fixes the issue).

I think some WebKitGTK devs need to do some testing with HTTP/SOCKS proxies because, it's not really usable today (see https://bugs.webkit.org/show_bug.cgi?id=177935)
Comment 1 Nick White 2018-03-22 08:11:15 PDT
I can confirm seeing this, tested with surf and uzbl-next, using the privoxy proxy (which is set up to forward requests through tor).

It can be reliably reproduced by loading a resource heavy page like https://maps.google.com

To my surprise Cédric's workaround worked for me, too, namely right-clicking on a "loading" resource and opening it in a new tab; all the locked resources then actually load.
Comment 2 Aleksei Lazarev 2018-11-12 05:37:30 PST
Created attachment 354550 [details]
Running youtube.com/tv on MiniBrowser/WebKitGTK-2.22.3 with http_proxy

No posters are visible on Youtube/TV in case of MiniBrowser running with http_proxy
Comment 3 Aleksei Lazarev 2018-11-12 05:38:45 PST
Created attachment 354551 [details]
Postern appearing in a minute on MiniBrowser with http_proxy

In a minute all the needed posters are shown
Comment 4 Aleksei Lazarev 2018-11-12 05:45:02 PST
Parameters to build MiniBrowser:
cmake -DPORT=GTK -DENABLE_OPENGL=ON -DENABLE_GLES2=ON -DENABLE_MINIBROWSER=ON -DCMAKE_BUILD_TYPE=Release -DENABLE_WEBGL=ON -DENABLE_ENCRYPTED_MEDIA=ON -DENABLE_MEDIA_SOURCE=ON -GNinja ..

Parameters to run MiniBrowser:
./bin/MiniBrowser --enable-mediasource=true --proxy=http://127.0.0.1:3128 http://youtube.com/tv

Proxy-server is trafficserver.

The issue is that posters are not shown for a minute after Youtube/TV page loaded. During this delay no any traffic b/w MiniBrowser and proxy.

After MiniBrowser closing there are such error messages in the log:

(process:12987): libsoup-CRITICAL **: 12:48:44.242: soup_connection_disconnect: assertion 'SOUP_IS_CONNECTION (conn)' failed

(process:12987): libsoup-CRITICAL **: 12:48:44.242: soup_connection_disconnect: assertion 'SOUP_IS_CONNECTION (conn)' failed

The issue is not reproduced on "Debug"-built MiniBrowser - all the posters are shown almost immediately.
Comment 5 Michael Catanzaro 2018-11-12 08:19:47 PST
(In reply to Aleksei Lazarev from comment #4)
> -DENABLE_OPENGL=ON -DENABLE_GLES2=O

(Just a note: these flags are mutually-exclusive. I assume ENABLE_GLES2 wins and disables desktop OpenGL support. Maybe vice-versa.)

(In reply to Aleksei Lazarev from comment #4)
> (process:12987): libsoup-CRITICAL **: 12:48:44.242:
> soup_connection_disconnect: assertion 'SOUP_IS_CONNECTION (conn)' failed
> 
> (process:12987): libsoup-CRITICAL **: 12:48:44.242:
> soup_connection_disconnect: assertion 'SOUP_IS_CONNECTION (conn)' failed

The good news is that you can get a backtrace for these by setting the environment variable G_DEBUG=fatal-criticals. Then report it at https://gitlab.gnome.org/GNOME/libsoup/issues with the backtrace. If we're really lucky, the criticals might even be related to this proxy bug report. (And if we're not lucky, at least you found and properly reported another bug.)

> The issue is not reproduced on "Debug"-built MiniBrowser - all the posters
> are shown almost immediately.

Huh, that's weird. Normally debug builds are extremely slow.
Comment 6 Aleksei Lazarev 2018-11-13 04:35:43 PST
(In reply to Michael Catanzaro from comment #5)
> (In reply to Aleksei Lazarev from comment #4)
> > -DENABLE_OPENGL=ON -DENABLE_GLES2=O
> 
> (Just a note: these flags are mutually-exclusive. I assume ENABLE_GLES2 wins
> and disables desktop OpenGL support. Maybe vice-versa.)

They are not mutually exclusive, ENABLE_OPENGL and USE_OPENGL are different macros. Here is a piece from Source/cmake/OptionsGTK.cmake
if (ENABLE_OPENGL)
    # ENABLE_OPENGL is true if either USE_OPENGL or ENABLE_GLES2 is true.
    # But USE_OPENGL is the opposite of ENABLE_GLES2.
    if (ENABLE_GLES2)

> The good news is that you can get a backtrace for these by setting the environment variable G_DEBUG=fatal-criticals. Then report it at https://gitlab.gnome.org/GNOME/libsoup/issues with the backtrace.
Done
https://gitlab.gnome.org/GNOME/libsoup/issues/127