Bug 227360 – WebKitGTK fails to handle some keypresses when built with the GTK Quartz backend on macOS

• Status: NEW
• Component: WebKitGTK

# What's affected

Browsers built with WebkitGTK and the GTK Quartz backend. I've noticed this behavior while trying out the Nyxt browser[1] on macOS.

# How to reproduce

1. Build and run the MiniBrowser
2. Open any website with a text input field
3. Type "abc" into the input field

# What's expected to happen

"abc" is displayed in the input field.

# What actually happens

Nothing.

# The cause

The problem is caused by the input method handling code in WebKitGTK. When using the Quartz backend, WebKit throws out some text inputs that are passed through GTK's input method interface.

My understanding is that GTK based input method systems may choose to consume keypress events in order to compose non-alphabetic text[2][3][4]. The consumed keypresses are processed by the input method systems as part of the "preediting" phase, and the final composed text is passed back to WebKit through a "commit" signal[5].

There is a complication here however, because different input method implementations consume keypresses differently. Based on what I've observed, the iBus input method on Linux doesn't consume simple alphabetical inputs and leaves WebKit to handle keypress events directly. On the other hand, GTK's Quartz backend on macOS consumes simple alphabetical inputs[6] and immediately fires the "commit" signal, accompanied by a "preedit-changed" signal[7][8]. This in turn causes WebKit to ignore the keypress event[9] *and* the "commit" signal fired by GTK[10]. And hence the issues.

[1]: https://nyxt.atlas.engineer
[2]: https://github.com/WebKit/WebKit/blob/a705747a1538dbb82ebc30f11d5413e67a0fa758/Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp#L1101-L1102
[3]: https://github.com/WebKit/WebKit/blob/0c141f987eda765a8cc36509147542c160c52d0d/Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp#L99
[4]: https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/WebKit/UIProcess/API/gtk/WebKitInputMethodContextImplGtk.cpp#L178
[5]: https://developer.gnome.org/gtk3/stable/GtkIMContext.html
[6]: https://github.com/GNOME/gtk/blob/77f32a69c0a35ffd3a1a542a6057c1c6d13c793d/gdk/quartz/GdkQuartzView.c#L239-L240
[7]: https://github.com/GNOME/gtk/blob/77f32a69c0a35ffd3a1a542a6057c1c6d13c793d/modules/input/imquartz.c#L163-L164
[8]: https://github.com/GNOME/gtk/blob/77f32a69c0a35ffd3a1a542a6057c1c6d13c793d/modules/input/imquartz.c#L206
[9]: https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp#L116-L118
[10]: https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp#L326-L327

Created attachment 432180 [details]
Patch

[EWS Watchlist]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

I've uploaded a patch that I'm considering applying to the downstream macOS build of WebKitGTK in the Nix package manager for the time being. It seems to fix the problem, but I'm not too sure whether this is a good idea or not. Would applying this patch have any obvious unintended side effects? Any help would be appreciated.

[Carlos Alberto Lopez Perez]

(In reply to discuss from comment #3)
> I've uploaded a patch that I'm considering applying to the downstream macOS
> build of WebKitGTK in the Nix package manager for the time being. It seems
> to fix the problem, but I'm not too sure whether this is a good idea or not.
> Would applying this patch have any obvious unintended side effects? Any help
> would be appreciated.

It seems it has unintended side effects.

As far as I can see this patch made the WebKitGTK API tests to fail on the CI, check the red bubble above -> https://ews-build.webkit.org/#/builders/34/builds/38608