Open Bug 1830702 Opened 1 year ago Updated 1 year ago

firefox does not honor my gtk3 key theme

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
Firefox 112
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: wai, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Explained below.

Actual results:

Explained below

Expected results:

Hello,

Years ago I reported a similar issue that was fixed recently. Late but
sure :-), this encourages me to nitpick on the same topic.

I use the gtk3 key theme pasted bellow. Among other things, it allows
me to navigate menus with vi keys in any gtk3 application except for
Firefox. More precisely the "menu" part at the end of the code.

Let me take the opportunity to make a generic suggestion. Many will
agree with me that the ideal thing would be for firefox to respect the
configuration of the system interface, as it did in its beginnings. I
know GTK developers aren't exactly helpful in documenting what they do,
but it's also true that you guys seem more busy imitating what other
popular browsers do to keep the cattle happy.

/*

  • ~/.themes/Vi/gtk-3.0/gtk-keys.css
  • GtkMovementStep:
  • @GTK_MOVEMENT_LOGICAL_POSITIONS: Move forward or back by graphemes
  • @GTK_MOVEMENT_VISUAL_POSITIONS: Move left or right by graphemes
  • @GTK_MOVEMENT_WORDS: Move forward or back by words
  • @GTK_MOVEMENT_DISPLAY_LINES: Move up or down lines (wrapped lines)
  • @GTK_MOVEMENT_DISPLAY_LINE_ENDS: Move to either end of a line
  • @GTK_MOVEMENT_PARAGRAPHS: Move up or down paragraphs
  •                                (newline-ended lines)
  • @GTK_MOVEMENT_PARAGRAPH_ENDS: Move to either end of a paragraph
  • @GTK_MOVEMENT_PAGES: Move by pages
  • @GTK_MOVEMENT_BUFFER_ENDS: Move to ends of the buffer
  • @GTK_MOVEMENT_HORIZONTAL_PAGES: Move horizontally by pages
    */

@binding-set text-entry
{
bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) };
bind "<ctrl>h" { "delete-from-cursor" (chars, -1) };
bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) };
bind "<ctrl>e" { "move-cursor" (paragraph-ends, 1, 0) };
bind "<ctrl>b" { "move-cursor" (paragraph-ends, -1, 0) };
}
@binding-set text-view
{
bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) };
bind "<ctrl>h" { "delete-from-cursor" (chars, -1) };
bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) };
bind "<ctrl>e" { "move-cursor" (paragraph-ends, 1, 0) };
bind "<ctrl>b" { "move-cursor" (paragraph-ends, -1, 0) };

}
@binding-set tree-view
{
bind "j" { "move-cursor" (display-lines, 1) };
bind "k" { "move-cursor" (display-lines, -1) };
bind "l" { "move-cursor" (logical-positions, 1) };
bind "h" { "move-cursor" (logical-positions, -1) };
bind "<shift>j" { "move-cursor" (display-lines, 1) };
bind "<shift>k" { "move-cursor" (display-lines, -1) };
}
@binding-set menu
{
bind "j" { "move-current" (next) };
bind "k" { "move-current" (prev) };
bind "l" { "move-current" (child) };
bind "h" { "move-current" (parent) };
}
entry { -gtk-key-bindings: text-entry; }
textview { -gtk-key-bindings: text-view; }
treeview { -gtk-key-bindings: tree-view; }
menu { -gtk-key-bindings: menu; }

/* End of file */

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Priority: -- → P3

<pre>
This is bugzilla, right? After reading the "priority" descriptions
here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1830702

I'm in the doubt if this place is for people asking for new features. ;-)
</pre>

(In reply to Walter Alejandro Iglesias from comment #2)

<pre>
This is bugzilla, right? After reading the "priority" descriptions
here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1830702

I'm in the doubt if this place is for people asking for new features. ;-)

The link I wanted to paste above was this:

https://wiki.mozilla.org/Bugzilla:Priority_System

Any chance you could bisect this?

$ pip3 install --user mozregression
$ mozregression --good 102 # Assuming 102 worked, change as needed

That should give us a push log so that we can identify what broke it.

Flags: needinfo?(wai)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Any chance you could bisect this?

$ pip3 install --user mozregression
$ mozregression --good 102 # Assuming 102 worked, change as needed

That should give us a push log so that we can identify what broke it.

Hi Emilio,

I'm not familiarized with python.
Running openbsd here, I installed the package that comes with pip3, but after running
the first command you told me I get this error:

error: subprocess-exited-with-error
Getting requirements to build wheel did not run successfully.

Flags: needinfo?(wai)

(In reply to Walter Alejandro Iglesias from comment #5)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Any chance you could bisect this?

$ pip3 install --user mozregression
$ mozregression --good 102 # Assuming 102 worked, change as needed

That should give us a push log so that we can identify what broke it.

Hi Emilio,

I'm not familiarized with python.
Running openbsd here, I installed the package that comes with pip3, but after running
the first command you told me I get this error:

error: subprocess-exited-with-error
Getting requirements to build wheel did not run successfully.

Hi again Emilio,

I could get running what you asked me in a debian system I have in an old laptop.
It spawned a nightly version of firefox, what should I do now, what info you need?

For each build that spawns, you need to use it, see if it reproduces the bug, and reply good/bad as needed on the terminal.

By the way, now I realize that you're looking for a "regression", you assume
it worked in recent releases, right? Firefox stopped honoring the system interface
(gtk widget in the unix* case) many years ago (that's what motivated my suggetion
in my first message). I have no idea in which version of firefox this worked, perhaps
it never worked with gtk3 (or even with gtk2).

So far you didn't commit any changes, right?
In the 103.0a1 version that mozregression spawned, the bug is still there. :-)

Besides, you can reproduce the bug yoursefl in any unix-like system.
Just copy the code I pasted in my first message to this file:

~/.config/themes/Vi/gtk-3.0/gtk-keys.css

Then add this line to gtk3 settings.ini:

$ echo gtk-key-theme-name=Vi >> ~/.config/gtk-3.0/settings.ini

Once you did the above open firefox preferently within a standalone
window manager (if you use a desktop environment you'll need to tell
it to use the Vi key theme in its configuration), press first Alt-Key to open
the menu and then try to navigate menus using j, k, l, h.

Ah, sorry, I read comment 0 as "this used to work and doesn't now". But yeah I don't think this ever worked, and sort of using native GTK menús, which is non-trivial for a variety of reasons, we'd have to somehow reimplement their whole key binding mechanism..

I think we might have something to support GTK key bindings for text input? Seems vaguely familiar. Masayuki, do you know if such a mechanism exists and whether it could be extensible to menús or what not?

Flags: needinfo?(emilio)

The "similar issue" I mention in my frist message (which years ago I reported here),
was a text input key from that same gtk key theme configuration, the C-w bind, which
in unix systems is traditionally bound to "delete one word backwards" (also present in the
Emacs key theme provided in a default install in /usr/local/share/themes in unix systems).
The reason why that key had stopped working was because, at some point, it was overridden by
the "close tab" firefox keystroke. That was fixed recently (I couldn't tell you exactly in which
release). I mention this because the other settings you see in my gtk key theme file are well
recognized by firefox, it's only the menu part what remains pending.

Err, I meant to ni? Masayuki in comment 10, see above.

Flags: needinfo?(emilio) → needinfo?(masayuki)

Currently, nsXULPopupManager::HandleKeyboardEventWithKeyCode refers only the .key value.
https://searchfox.org/mozilla-central/rev/32c74afbb24dce4b5dd6b33be71197e615631d71/layout/xul/nsXULPopupManager.cpp#2453-2458

Therefore, the native key bindings for editable widgets are not handled.

I think that WidgetKeyboardEvent should have ComputeNavigationKeyCode and ComputeNavigationKeyNameIndex like the remapping methods for WritingMode.
https://searchfox.org/mozilla-central/rev/32c74afbb24dce4b5dd6b33be71197e615631d71/widget/TextEvents.h#440-456,458-479

Then, it should call InitAllEditCommands and consider the key codes with mEditCommandsForMultiLineEditor.

Flags: needinfo?(masayuki)
Severity: -- → S3
Component: Widget: Gtk → DOM: UI Events & Focus Handling

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Priority: P3 → --
You need to log in before you can comment on or make changes to this bug.