It bails out in vte.c, beginning of vte_terminal_key_press(), line 5300ish:
"First, check if GtkWidget's behavior already does something with this key."

Workaround:
Place this in ~/.config/gtk-3.0/gtk.css:

@binding-set NoKeyboardNavigation {
     unbind "<shift>F10";
     unbind "<control>F1";
}

* {
     gtk-key-bindings: NoKeyboardNavigation;
}

Would be nice if it worked out of the box, without hacking configs.

It's very hard to gather information what Ctrl+F1 is meant to do, Google only barely helps. The most relevant finding seems to be this: https://bugs.webkit.org/show_bug.cgi?id=25525. As much as I understand, it toggles whether the tooltip is shown for the mouse hover element (default) or the focused element.

In g-t the only place where this seems to properly work is Profile Prefs -> Color palette, here the 16 colored buttons do have tooltips. In the main terminal area the tooltips for the tab titles stop working if you focus them and ask for this tooltip mode.

Also, this seems to be an accessibility thing for me, yet I see no way in g-t to focus the tabs without the mouse.

I've checked gnome-control-center and compiz/unity settings, there are plenty of shortcuts defined there, but no sign of Ctrl+F1. All these, along with the fact that Google doesn't give an explicit answer what this keycombo does (nor the other way around: how do I see the tooltip of the focused element), makes it a pretty pointless and undiscoverable feature to me. I think it's more important that the terminal emits the corresponding escape sequence.

So we need to partially revert commit 46b7464576141d69bd0dce16409141cfb26a8225 (the use of GtkBinding to copy/paste/), and then we can remove the chaining up to the parent class for handling the keys.

I added a gtk_binding_entry_skip(...) and it made Ctrl+F1 work, but it simultaneously emitted the escape sequence and toggled the tooltip behavior. I guess that chaining stuff you mentioned is what we need. It's all new topic to me. Not sure if I can figure it out today-tomorrow. On one hand it'd be nice since many kbd fixes go into 0.36. On the other hand it's really low prio :)

Created attachment 272075 [details] [review]
Seems to work

This patch seems to work. Does it make any sense what I'm doing?

I'd rather stop using gtkbinding altogether and just handle all the keys directly in the key press handler.

Would it still read keys from gtk.css then? The whole net is full of the above workaround for disabling Shift+F10, would it still work?

Shift-F10 or Menu key wouldn't work at all then since it's handled by gtkwidget's keybindings. We'd have to handle it ourself then.

Also I wonder why bug 153265 used F16, F18, F20 instead of
GDK_KEY_(Cut|Copy|Paste).

Sounds like too much refactoring for a last minute change, doesn't it? I mean, whatever we'd do with Shift-F10 there should remain a way for power users to enable/disable this and the current approach wouldn't work, so we'd need something brand new. Maybe even a corresponding g-t prefs checkbox.

How about my patch for now, and keeping a bug for future cleanup? (Provided of course that my patch doesn't have any bugs or side effects.) There are other similar issues to be addressed, e.g. possibility of disabling F11 fullscreen...

Sure, for 0.36.0 this is good enough.

Fixed in vte-0-36. Keeping open for vte-next.

Continued in bug 726537.

Fixed on master too, but keeping open since the committed patch was just a quick hack, not a real fix.

I think we should remove the chaining up to the parent class ::key-press-event handler in vte_terminal_key_press(). However, that will require handling Shift-F10/MenuKey ourself (used to pop up the context menu via popup-menu signal), and need a way to disable it from g-t. We should introduce a global setting for that which'll also make us not use up all the other keys we handle in key_press (copy, paste, etc) (except for the IM, of course).

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2068.