Motivation

• GTK3 themes either don't or can't implement a GTK2 equivalent and distributions are using these GTK3 themes and so Firefox looks different.

• New toolkit features are added to GTK3 but rarely ported to GTK2. This includes support for input events such as touch events and Wayland.

• GTK3 provides the option of rendering native widgets to CPU memory surfaces, which would allow Thebes layers to be rendered to these surfaces before being uploaded for compositing.

What needs to be done

The dependencies of bug 627699 track some of the major code changes required. There are also annotations in the code where the port is not complete: [1] [2]

Plugins

Plugins use GTK2. GTK libraries do not version symbols and so if a GTK2 plugin is loaded into a process that already has GTK3 libaries loaded for global relocations, then symbol relocation for the plugin, even loaded with RTLD_LOCAL, will find the GTK3 symbols first (see man 3p dlopen). GTK2 and GTK3 also use the same names for different GObject types, so no GTK2 functions may run, even using RTLD_LOCAL, in a process also using GTK3.

Therefore a plugin-container executable needs to be built in a way that does not pull in GTK3.

The biggest issue is how to adjust the build system to do this in a maintainable manner, while still building the browser process with GTK3. gtest has a similar need to build multiple libxuls with different sets of source files ([3]). A GTK2 plugin-container has the additional requirement of having to compile the same source file with different preprocessor defines.

An ideal solution would not include all of Gecko in the plugin-container but only what is necessary. This includes mfbt, xpcom, ipc/chromium, parts of gfx, and dom/plugins/ipc.

Currently, plugin mimetypes are read from the browser process. This occasionally needs to happen for all plugins to create a database for determining which, if any, plugin is used for which mimetypes. Perhaps we could get lucky with RTLD_LOCAL dlopen if the plugin runs no functions and has no static constructors that use GTK/GDK, and GTK has no constructors, but this is delicate at best. A better approach is to read mimetypes from the plugin process and shut down these processes when done.

Cairo

The GTK3 port is currently designed to use system cairo for Gecko drawing. Eventually, Gecko will probably use a different graphics system, but GTK themes will still need a system cairo context to draw. This will require a gfxCairoNativeRenderer or similar (c.f. [4]) to create a system-cairo context around a surface with appropriate clipping.

Builds and Tests

We need GTK3 installed on build and test machines, and to decide whether to ship GTK2 or GTK3 ports or both.