Focus behavior with key bindings

[Yotam Leibovici]

Hi,

In the default state, without any key bindings configured, when a user annotates a specific layer, the focus automatically jumps to the first feature of that layer, allowing it to be filled in. If the values for that feature are selected from a tagset, then once a value is chosen, the focus jumps to the next feature within the layer. This is a helpful behavior that enables efficient and convenient annotation.
However, once any key binding is defined, this behavior stops, and the user has to manually focus on each relevant feature in order to annotate it.
Is this the intended behavior?
It would be great if the automatic focusing could still happen even when key bindings are defined.

Thanks!

[Richard Eckart de Castilho]

Hi Yotam,

> On 24. Jul 2025, at 11:44, Yotam Leibovici <yotam.l...@gmail.com> wrote:
>
> In the default state, without any key bindings configured, when a user annotates a specific layer, the focus automatically jumps to the first feature of that layer, allowing it to be filled in. If the values for that feature are selected from a tagset, then once a value is chosen, the focus jumps to the next feature within the layer. This is a helpful behavior that enables efficient and convenient annotation.
> However, once any key binding is defined, this behavior stops, and the user has to manually focus on each relevant feature in order to annotate it.
> Is this the intended behavior?

Imagine you have a hot-key bound to the key "a". Now you create an annotation
and the focus moves directly into an input field for the label. Now you press
"a" because you want to write a label starting with that letter.

In order to enable you to write that label, key bindings are disabled when the
focus is in an input field.

For that reason, the focus also does not jump into an input field when there
are key bindings because doing so would render the key binding ineffective.
You would first have to click somewhere to move the focus out of the input
field and then you would be able to use the keybinding.

So what you observe is intended behavior. If you have an alternative idea
how to resolve the conflict between free-text input and keybindings, let me
know.

Cheers,

-- Richard

[Yotam Leibovici]

Hi Richard,

Thank you very much for the detailed explanation. I understand the issue that arises when enabling key bindings while a text field is focused.

1. I would suggest allowing key bindings that are not taken by the operating system or the browser, so there's no chance they would interfere with other text-editing actions. I'm not sure if such bindings exist, but there may be rare combinations — like Ctrl + Shift + <key> — that could be safe to allow even during editing.
2. Given the current behavior, I would suggest choosing one of the following options: a. Automatically move the focus to the first editable field, while relying on the Escape key to remove focus in case the user wants to use a key binding. b. Do not automatically focus the first editable field, but allow jumping to it with a single keystroke (e.g., Tab). Currently, at least on Windows/Chrome, it takes about six Tab presses to get there.

In the current situation, I unfortunately had to give up on using key bindings even though they were helpful, and I believe one of these suggestions could make it easier to use both key bindings and feature editing smoothly.

Of course, I understand the complexity of the matter and appreciate the thought and effort involved.

ב-יום חמישי, 24 ביולי 2025 בשעה 15:16:14 UTC+3, Richard Eckart de Castilho כתב/ה:

[Richard Eckart de Castilho]

Hi Yotam,

> On 24. Jul 2025, at 15:06, Yotam Leibovici <yotam.l...@gmail.com> wrote:
>
> • I would suggest allowing key bindings that are not taken by the operating system or the browser, so there's no chance they would interfere with other text-editing actions. I'm not sure if such bindings exist, but there may be rare combinations — like Ctrl + Shift + <key> — that could be safe to allow even during editing.

Key bindings vary across operating systems, browsers and locales - and of course user preferences.

Key bindings lose value the longer the key combinations are. Consider for example vim or emacs
which are notorious for their complex key bindings. When efficiency is key, having the most common
actions on single keys is best (cf. computer games) - sometimes in a two-hand setup where the other
hand is either on the mouse (as in INCEpTION) or on the cursor keys for navigation.

I believe forcing the user to assign complex keybindings would also render them unusable for most.

> • Given the current behavior, I would suggest choosing one of the following options: a. Automatically move the focus to the first editable field, while relying on the Escape key to remove focus in case the user wants to use a key binding. b. Do not automatically focus the first editable field, but allow jumping to it with a single keystroke (e.g., Tab). Currently, at least on Windows/Chrome, it takes about six Tab presses to get there.

That sounds like a good idea. I believe making it so that the tab order is optimized for access
to the editor sidebar should be doable. Would you like to help by opening an feature request
for this on the issue tracker?

Cheers,

-- Richard