Bug 150303 - [GTK] Accessing default web context before gtk_init results in drawing failure (Gtk-WARNING **: drawing failure for widget 'WebKitWebView': invalid value for an input Visual*)
Summary: [GTK] Accessing default web context before gtk_init results in drawing failur...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2015-10-18 09:24 PDT by Steef435
Modified: 2018-11-26 06:18 PST (History)
5 users (show)

See Also:

Minimal example for reproduction (371 bytes, text/x-csrc)
2015-10-18 09:25 PDT, Steef435
no flags Details
Patch (2.26 KB, patch)
2018-11-23 01:31 PST, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steef435 2015-10-18 09:24:25 PDT
On WebKit2GTK+ version 2.10.2, drawing failures occur when (in this order):

1. webkit_web_context_get_default() gets called
2. gtk_init() gets called
3. a window with a WebKitWebView gets shown

In this order, however, no errors occur:

1. gtk_init() gets called
2. webkit_web_context_get_default() gets called
3. a window with a WebKitWebView gets shown

I have attached a minimal example showing this behavior. When running this, the following warnings are printed from time to time:
Gtk-WARNING **: drawing failure for widget 'WebKitWebView': invalid value for an input Visual*

This behavior only started to appear recently, my guess would be from version 2.10.1 onward.
Comment 1 Steef435 2015-10-18 09:25:12 PDT
Created attachment 263423 [details]
Minimal example for reproduction
Comment 2 Adrian Perez 2018-09-24 15:01:52 PDT
Interestingly enough, the same kind of warnings are logged when building
Cog (https://github.com/Igalia/cog) with “-DCOG_USE_WEBKITGTK=ON”, and
after I have updated to WebKitGTK+ 2.22.x

While it might be possible to workaround this issue in many cases, it
is very annoying for programs which, for example, fetch the default
context, then its associated WebKitSettings, and change the initial
settings based on CLI flags *before* GTK+ has been initialized (in
Cog GTK+ is initialized by GtkApplication, and the default context
has been retrieved at least once precisely to setup CLI parsing).

A workaround has been to call gtk_init() early anyway, but it feels
dirty to do that: https://github.com/Igalia/cog/pull/63

IMHO it would be great if we could fix this regression, as we don't
know how many applications out there in the wild depend on this
behaviour, and it would be better to not break them if possible.
Comment 3 Carlos Garcia Campos 2018-11-08 01:32:54 PST
I can't reproduce this in current trunk
Comment 4 Carlos Garcia Campos 2018-11-08 03:18:39 PST
I still don't get the error message, but I'm getting a black screen in pages using AC. The problem is that PlatformDisplay::sharedDisplay() is called before gtk_init(), creating a new display instead of reusing the one opened by GTK+ in gtk_init(). This approach doesn't seem to work anymore when using AC, neither in X11 nor in wayland. The display is created by HardwareAccelerationManager, called when settings are initialized to check if the x server support xdamange and xcomposite in case of x11 and whether the wayland nested compositor failed in case of wayland. Both things are unlikely to happen, and they are already handled by AcceleratedBackingStoreX11 and AcceleratedBackingStoreWayland in their create() method. So, we could probably remove those checks and not change the settings based on system capabilities.
Comment 5 Carlos Garcia Campos 2018-11-23 01:27:53 PST
I've changed my mind here, we should ensure that gtk init has been initialized before creating the default display. Application that want to handle gtk command line arguments either call gtk_init earlier or use GtkApplication.
Comment 6 Carlos Garcia Campos 2018-11-23 01:31:27 PST
Created attachment 355504 [details]
Comment 7 Michael Catanzaro 2018-11-23 09:06:59 PST
GTK+ command line args are deprecated anyway.
Comment 8 Carlos Garcia Campos 2018-11-26 06:18:44 PST
Committed r238492: <https://trac.webkit.org/changeset/238492>