WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
273780
REGRESSION(
273922@main
): [GTK] Epiphany keyboard shortcuts broken with non-Latin keyboard layout
https://bugs.webkit.org/show_bug.cgi?id=273780
Summary
REGRESSION(273922@main): [GTK] Epiphany keyboard shortcuts broken with non-La...
Michael Catanzaro
Reported
2024-05-06 10:36:11 PDT
Moving this from
https://gitlab.gnome.org/GNOME/epiphany/-/issues/2312
, the problem is since Epiphany 46 keyboard shortcuts no longer work when using non-Latin keyboard layouts, like Ukranian or Hebrew. Currently we only consider the keyval when activating application accelerators. We need to consider the raw keycode as well. E.g. on a Hebrew keyboard pressing Ctrl+א should open a new tab, because the same key is used for both א and T.
Attachments
Add attachment
proposed patch, testcase, etc.
Michael Catanzaro
Comment 1
2024-05-06 10:40:53 PDT
(This is *sort of* a regression from
273922@main
, except in practice it probably only affects Epiphany. Only matters if the application allows the web view to process key events before it allows its GtkWindow to do so, which has to be done manually.)
Michael Catanzaro
Comment 2
2024-05-06 10:44:36 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/28181
EWS
Comment 3
2024-05-07 05:34:51 PDT
Committed
278456@main
(48d82b12d119): <
https://commits.webkit.org/278456@main
> Reviewed commits have been landed. Closing PR #28181 and removing active labels.
Michael Catanzaro
Comment 4
2024-07-29 08:55:32 PDT
Reopening because something is wrong and this isn't working. See:
https://gitlab.gnome.org/GNOME/epiphany/-/issues/2396
Michael Catanzaro
Comment 5
2024-07-31 14:17:12 PDT
gtk_accelerator_name_with_keycode() is returning "<Control>hebrew_aleph" which of course doesn't match any actions. So that doesn't work at all. But three months ago, I was convinced that it did work. The question is why. Did I trick myself, or did something change?
Michael Catanzaro
Comment 6
2024-07-31 14:51:10 PDT
Guess: this never worked, and I tricked myself by testing on about:overview, where the web view is not focused and not actually receiving the key press events?
Michael Catanzaro
Comment 7
2024-08-05 11:04:53 PDT
I don't have a solution for this. We might need to revert
273922@main
, which would be unfortunate because that will bring back other serious bugs, but at least then all keyboard layouts would be equally broken. (I hesitate to treat non-Latin keyboard layouts worse off than Latin layouts.)
darkblaze69
Comment 8
2024-08-28 12:19:29 PDT
fwiw, libreoffice in gtk4 also suffers from this issue. Is it maybe more general issue in gtk4?
https://bugs.documentfoundation.org/show_bug.cgi?id=161589
Michael Catanzaro
Comment 9
2024-08-28 13:25:28 PDT
No, this is a WebKit bug.
Michael Catanzaro
Comment 10
2024-09-06 05:38:21 PDT
Let's bring back key event reinjection to get back to the state we had before I broke Hebrew/Ukrainian keyboards. That won't work properly either, but at least it will be equally broken for everyone.
Michael Catanzaro
Comment 11
2024-09-06 05:56:26 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/33242
EWS
Comment 12
2024-09-06 06:49:53 PDT
Committed
283267@main
(5978873cc8be): <
https://commits.webkit.org/283267@main
> Reviewed commits have been landed. Closing PR #33242 and removing active labels.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug