Bug 183163 – [SOUP] WebKitGTK randomly hangs while using a http proxy

• Component: WebKitGTK
• Status: NEW

[Cédric Bellegarde]

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)

[Nick White]

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.

[Aleksei Lazarev]

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

[Aleksei Lazarev]

Created attachment 354551 [details]
Postern appearing in a minute on MiniBrowser with http_proxy

In a minute all the needed posters are shown

[Aleksei Lazarev]

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.

[Michael Catanzaro]

(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.

[Aleksei Lazarev]

(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