Created attachment 466656 [details] test case of the bug The modifier key (ctrlKey, shiftKey,...) properties of the WheelEvent are always false when read from a wheel event callback. Tested in Epiphany 44.3-1 and in an embedded application using Webkit2gtk 2.40.2-1, on Arch Linux. A test case is provided as an attachement. When scrolling over the red square while the Ctrl key is held down, should turn green. Passes on Firefox 114.0.
I've done a first investigation myself on the question, and I found the problem to be here : https://github.com/WebKit/WebKit/blob/ef93c1b412c09e10975907c8fd683269eb36a413/Source/WebKit/Shared/gtk/NativeWebWheelEventGtk.cpp#LL41C13-L41C13 The modifier events that could have been extracted from the GtkEventScroll are not transmitted to the constructor of WebEvent. This is handled better for key presses (https://github.com/WebKit/WebKit/blob/ef93c1b412c09e10975907c8fd683269eb36a413/Source/WebKit/Shared/gtk/WebEventFactory.cpp#L259), where a factory function parses the GtkEventScroll.state property and transmits the modifier keys using the modifiersForEvent(const GdkEvent*) function. This is my first time delving into the Webkit codebase and I'm not a professional programmer so I don't really want to make the change myself, but I can try if nobody's up for it...
See also https://github.com/WebKit/WebKit/blob/ef93c1b412c09e10975907c8fd683269eb36a413/Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp#L1409 for where the event is handled on the Gtk side and first dispatched to the page Proxy. Strangely enough the key modifiers are even queried a few lines up (l402), but never checked again further down the call stack.
Nice investigation. This probably explains why all those "hold Ctrl to scroll" maps on various websites do not work.
Pull request: https://github.com/WebKit/WebKit/pull/14863
Committed 265104@main (c313668f2cf7): <https://commits.webkit.org/265104@main> Reviewed commits have been landed. Closing PR #14863 and removing active labels.