[Webkit-unassigned] [Bug 227360] New: WebKitGTK fails to handle some keypresses when built with the GTK Quartz backend on macOS

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=227360

            Bug ID: 227360
           Summary: WebKitGTK fails to handle some keypresses when built
                    with the GTK Quartz backend on macOS
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Mac (Intel)
                OS: macOS 10.14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: discuss at midchildan.org
                CC: bugs-noreply at webkitgtk.org

# 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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210624/4f51e040/attachment.htm>