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.
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.
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
Probably a GTK 3 -> GTK 4 change, then, indeed.
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.
> 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.
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.
(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.
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.
Moved to https://gitlab.gnome.org/GNOME/epiphany/-/issues/2173