Open Bug 1883833 Opened 1 year ago Updated 1 year ago

Can't override native key bindings from GTK Emacs theme

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 125
defect

Tracking

()

UNCONFIRMED

People

(Reporter: markus, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

  1. Use GNOME with the dconf setting /org/gnome/desktop/interface/gtk-key-theme set to Emacs
  2. Download latest Firefox Nightly
  3. Change ui.key.textcontrol.prefer_native_key_bindings_over_builtin_shortcut_key_definitions from the default true to false
  4. Restart browser
  5. Open https://github.com/mozilla/pdf.js/blob/master/package.json
  6. Click into the source code to focus the textarea
  7. Press Ctrl-F

Actual results:

The cursor moves one character forward.

Expected results:

The browser's search dialog should have opened, since it's builtin shortcut should override the native Ctrl-F shortcut from the GTK Emacs key theme.

It's especially annoying on sites like GitHub or Notion, which use textareas or content-editable for a lot of their main content, but you also want to frequently search.

I believe this used to work at some point, at least before support for Emacs keys was properly fixed (see https://bugzilla.mozilla.org/show_bug.cgi?id=1191862 and others).

Maybe I'm also misunderstanding how this setting should work.

Also, I go back and forth if I actually want Emacs keys in Firefox or not :) I really do for shortcuts like Ctrl-A/E, Ctrl-U, and sometimes (but not always) Ctrl-W, but really don't use Ctrl-B/F for example. Ideally it would be possible to choose native or builtin shortcuts for each of them, or customize the builtin shortcuts. But for now I'd be satisfied if I could just have Firefox ignore Emacs keys that clash with builtin shortcuts.

Hello! I have tried to reproduce the issue with firefox 126.0a1(2024-04-08) on Ubuntu 22.04, unfortunately I wasn't able to reproduce the issue on my end.
Could you please answer the following questions in order to further investigate this issue:

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
  3. Do you have any addons installed? If yes could you please list them?
Flags: needinfo?(markus)

Hey Negritas, thanks! I can still reproduce with latest nightly and a fresh profile.

Also verified now that changing the dconf gtk-key-theme back to Default avoids the problem, as expected.

I guess it's possible that this was caused by a change in GTK, I'm on Debian sid using libgtk-3-0t64 3.24.41-4, looks like Ubuntu 22.04 has 3.24.33. Although I didn't find anything relevant in the changelog at https://gitlab.gnome.org/GNOME/gtk/-/blob/main/NEWS.pre-4.0.

Not sure when exactly this started since I only recently changed the setting, I only believe that it still worked ~2 years ago when I was commenting in https://bugzilla.mozilla.org/show_bug.cgi?id=1191862. But maybe this specific case with Ctrl-F never worked correctly.

Another observation: Ctrl-B is the corresponding Emacs shortcut to move one character backwards. This works correctly in the location bar (as does Ctrl-F), and on GitHub it actually correctly triggers the file navigation sidebar when focused on the textarea. So it seems that shortcuts mapped by the website are intercepted on text fields, but Firefox's builtin shortcuts aren't.

Flags: needinfo?(markus)

The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Theme
Component: Theme → Widget: Gtk
Product: Firefox → Core
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.