The key event reinjection logic is causing many problems, see https://gitlab.gnome.org/GNOME/epiphany/-/issues/1915 and bug #260602, and relies on gdk_display_put_event(), which is deprecated and will be removed in GTK 5. Let's remove all of this logic and have the web view always consume all GTK events. If the corresponding DOM event is not handled, then we need to manually activate application accelerators to ensure keyboard shortcuts keep working as expected.
Pull request: https://github.com/WebKit/WebKit/pull/17609
(In reply to Michael Catanzaro from comment #1) > Pull request: https://github.com/WebKit/WebKit/pull/17609 Hi Benjamin, this pull request removes the key event reinjection that you dislike. But: * I have failed to convince Carlos Garcia that this is a good idea, so it's not on track to land. * We still have scroll wheel event reinjection, and I have no clue what to do about that. If we don't find a solution for wheel events, and if GTK 5 does not have gdk_display_put_event(), then apps like Geary and Evolution will probably never be able to port to GTK 5. Email clients use a scrolled view containing multiple web views and the parent scrolled view needs to know whether the web view handled the wheel event or not; if WebKit always handles the event, then scrolling the parent view would become extremely difficult as you would have to position the mouse cursor in the margin outside the web views, and if WebKit never handles the event, then the parent view would always scroll inappropriately. But WebKit will not ever be able to handle the events synchronously as that would be devastating for performance. (I think it's not a problem for scrolling via keyboard because that is expected to only scroll the parent view in these applications.) One option would be to simply un-deprecate gdk_display_put_event() and instead document that it should be rarely used.
My goal for GTK5 - but I'm not thinking about input very much, and certainly not atm - is to get scroll events to be grouped into sequences - like touch events. And that means ensuring that sequences are consistent, so that you can use it for kinetic scrolling and so that once you started scrolling, there's not suddenly a spinbutton taking over your scroll events because the mouse handed up over the spinbutton for this one frame. And you can't really have such an infrastructure working well if you allow random code to inject random events. That doesn't make your use case invalid, and someone will have to figure out how to deal with that, but I'm pretty sure that it means gdk_display_put_event() will need a replacement.
Hm. Maybe we can save wheel events for later, and land the key event removal now regardless, so that we can fix Google Docs and other websites that rely on keyboard shortcuts. This is a frequent complaint from users.
(In reply to Michael Catanzaro from comment #2) > (In reply to Michael Catanzaro from comment #1) > > Pull request: https://github.com/WebKit/WebKit/pull/17609 > > Hi Benjamin, this pull request removes the key event reinjection that you > dislike. But: > > * I have failed to convince Carlos Garcia that this is a good idea, so it's > not on track to land. Well, I'm not against the change itself, I never liked the event reinjection, what I don't want is making decisions now based on something that doesn't even exist yet (GTK5).
(In reply to Carlos Garcia Campos from comment #5) > Well, I'm not against the change itself, I never liked the event > reinjection, what I don't want is making decisions now based on something > that doesn't even exist yet (GTK5). Let's focus on the immediate problem then. Keyboard shortcuts are broken on websites, and users are complaining today. Browsers cannot fix this without changes in WebKitGTK.
Committed 273922@main (fd1f0b783bb7): <https://commits.webkit.org/273922@main> Reviewed commits have been landed. Closing PR #17609 and removing active labels.