Bug 227360 - WebKitGTK fails to handle some keypresses when built with the GTK Quartz backend on macOS
Summary: WebKitGTK fails to handle some keypresses when built with the GTK Quartz back...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Mac (Intel) macOS 10.14
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-24 10:00 PDT by discuss
Modified: 2021-09-02 20:37 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.02 KB, patch)
2021-06-24 10:09 PDT, discuss
discuss: review?
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description discuss 2021-06-24 10:00:54 PDT
# 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
Comment 1 discuss 2021-06-24 10:09:55 PDT
Created attachment 432180 [details]
Patch
Comment 2 EWS Watchlist 2021-06-24 10:11:01 PDT
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
Comment 3 discuss 2021-06-24 10:21:29 PDT
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.
Comment 4 Carlos Alberto Lopez Perez 2021-09-02 20:37:21 PDT
(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