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*)

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Steef435]

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.

[Steef435]

Created attachment 263423 [details]
Minimal example for reproduction

[Adrian Perez]

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.

[Carlos Garcia Campos]

I can't reproduce this in current trunk

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

Created attachment 355504 [details]
Patch

[Michael Catanzaro]

GTK+ command line args are deprecated anyway.

[Carlos Garcia Campos]

Committed r238492: <https://trac.webkit.org/changeset/238492>