Bug 248144
| Summary: | [GTK4] PlatformKeyboardEvent::currentStateOfModifierKeys is not implemented | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | alicem, bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=248143 | ||
| Bug Depends on: | |||
| Bug Blocks: | 210100 | ||
Michael Catanzaro
PlatformKeyboardEvent::getCurrentModifierState (which is renamed to PlatformKeyboardEvent::currentStateOfModifierKeys in https://github.com/WebKit/WebKit/pull/6672) has hardcoded shift/ctrl/alt/meta all to 0. In GTK 3 the code did gtk_get_current_event_state(), but that's not possible in GTK 4. I also notice that PlatformKeyboardEvent::modifiersContainCapsLock hardcodes caps lock to 0.
At least shift and caps lock both actually work when typing in this Bugzilla.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alice Mikhaylenko
The real question is why it does that instead of having modifiers as part of the event already. Like that code was never correct to begin with.
Michael Catanzaro
(In reply to Alexander Mikhaylenko from comment #1)
> The real question is why it does that instead of having modifiers as part of
> the event already. Like that code was never correct to begin with.
The name of the function, PlatformKeyboardEvent::currentStateOfModifierKeys, is kinda unambiguous, though. It's asking for the *current* state of the modifier keys, not the state of modifier keys corresponding to any particular event. And it is a static function, not a method that operates on a particular event.
Looks like it's used only by DragController.cpp and EventHandler.cpp (plus some platform-specific places that don't affect GTK). In DragController it's used to synthesize mouse events, which looks pretty reasonable. In EventHandler.cpp it's again used to synthesize mouse events in EventHandler::fakeMouseMoveEventTimerFired.
So this code looks decent enough. Only problem is we need to implement it. I wonder if that's even possible with GTK 4.
Michael Catanzaro
*** This bug has been marked as a duplicate of bug 258965 ***