Bug 260602 – [GTK] Ctrl+<key> no longer sends keydown events

• Status: CLOSED
• Resolution: MOVED
• Component: WebKitGTK

[Pierre Ossman]

Something is currently very broken in the keyboard handling in Epiphany. It fails to send keydown events when Ctrl is pressed. This has a massive impact on applications that are keyboard focused, such as remote desktop tools (issue first seen in VMware).

You can easily test the bug by simply pressing Ctrl+C in the form here:

https://w3c.github.io/uievents/tools/key-event-viewer.html

When I do that here, I get:

1. keydown Control
2. keyup C
3. keyup Control

There should have been a keydown C between 1 and 2.

Tested with:

webkitgtk6.0-2.40.5-1.fc38.x86_64
epiphany-44.6-1.fc38.x86_64

Fedora 38 with Xorg.

[Michael Catanzaro]

When you say "no longer sends" I presume that means you know it used to work properly? Would sure help if we knew when it broke.

[Pierre Ossman]

I'm fairly certain this worked fine before my recent upgrade from Fedora 36 to Fedora 38. I use VMware fairly regularly, and it would be odd if I only just now happened to notice that Ctrl+C doesn't work. I think it is more likely it broke in the upgrade I just performed.

On the other hand, the WebKit version in Fedora 36 seems to have been about the same:

webkit2gtk3-2.40.1-1.fc36.x86_64

I cannot find a WebKit for GTK 4 among the Fedora 36 packages. Perhaps this is caused by a switch from GTK 3 to GTK 4?

The Epiphany package in Fedora 36 was:

epiphany-1:42.5-1.fc36.x86_64

[Michael Catanzaro]

Probably a GTK 3 -> GTK 4 change, then, indeed.

[Michael Catanzaro]

Well, unlikely as it might seem, this is actually an Epiphany bug. MiniBrowser is fine. Please report this on the Epiphany issue tracker; we can continue there. Epiphany has some code to try to ensure websites cannot hijack standard keyboard shortcuts like Ctrl+T and probably something is broken with that.

[Michael Catanzaro]

> Epiphany has some code to try to ensure websites cannot hijack standard keyboard shortcuts like Ctrl+T and probably something is broken with that.

Actually, all of that code is currently disabled due to https://gitlab.gnome.org/GNOME/epiphany/-/issues/1915. I have no clue what is going wrong.

[Michael Catanzaro]

The WebKitWebView is not receiving the missing key press event at all. EphyWindow does see the event, but it never makes it to the WebKitWebView. Something in between is eating the event, and there's not a lot in between.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #6)
> The WebKitWebView is not receiving the missing key press event at all.
> EphyWindow does see the event, but it never makes it to the WebKitWebView.
> Something in between is eating the event, and there's not a lot in between.

The hierarchy is:

EphyWindow
 AdwBreakpointBin
  AdwTabOverview
   AdwBin
    EphyFullscreenBox
     AdwToolbarView
      AdwToastOverlay
       EphyTabView
        AdwTabView
         AdwBin
          EphyEmbed
           GtkOverlay
            EphyWebView (is a WebKitWebView)

OK, so "there's not a lot in between" is not really true. But one of those things is handling the event before WebKit even sees it, so we can be confident it's either an Epiphany bug or a libadwaita bug, not a WebKit bug. Unfortunately I cannot find any suspicious key event controllers in Epiphany or libadwaita, so I might need to "bisect" my way through this hierarchy.

[Michael Catanzaro]

I bisected the widget hierarchy by creating GtkEventControllerKeys in each object's init method and hooking them up to dummy callbacks that just print when an event is received and then propagate the event. This works properly for all events except the "keydown c" event that is going missing. In this case, the AdwBreakpointBin never receives the key press event. This makes no sense because it's directly below the EphyWindow, which does receive the event.

We'll probably need a closer investigation inside GTK itself to figure out what is going wrong.

[Michael Catanzaro]

Moved to https://gitlab.gnome.org/GNOME/epiphany/-/issues/2173