Set focus to translation field on open from reading screen

[jzohrab]

On open from reading screen, the term is created, most natural thing would be to edit the translation. ref discord:

do you think it would be possible to activate this window (translation box) automatically by default after the term is searched in the primary dictionary?

[Jayanth-Parthsarathy]

Hey @jzohrab I would like to work on this. Please assign this to me.

[Jayanth-Parthsarathy]

Would adding a autofocus attribute to the {form.translation} field in the term/_form.html be a good start? It seems to work when I click on any of the terms on the read page.

[jzohrab]

Hi @Jayanth-Parthsarathy - thanks very much! (Sorry have been travelling and busy) Autofocus should only be set if the language and term are already set:

• If the form is opened to create a new term and the language isn't set, focus should go there
• if form is opened to create new and lang is set (b/c the user set the "current language" from home screen), focus goes to the term
• if lang and term are set, it should go to the translation.

Makes sense?

[Jayanth-Parthsarathy]

Understood, thanks for the clarification :)

[jzohrab]

@Jayanth-Parthsarathy did this work in #390 but I disabled it -- it has the unfortunate side-effect of pulling focus from the reading pane, which is a hassle when I'm quickly moving from term to term using the cursor keys. Perhaps there's a way to set the focus in the translation field when the form first gets the focus, so that the reading pane keeps the focus.

[cblanken]

Something else to note, is that some dictionaries will steal focus as well. For instance dwds.de will steal focus as soon as it loads after a term is clicked.

[jzohrab]

Yep, dictionaries stealing focus was part of what this ticket was originally trying to address -- at least, that's been a problem that was brought up in the past -- but addressing this issue creates too many problems with the current setup/js model of how Lute works (and I like how it currently handles things). It's a rough edge, but I'm personally not too concerned at the moment.

[cblanken]

This issue does cause me a fair amount of annoyance, so I'd like to take a look at it, unless @Jayanth-Parthsarathy wants to keep hacking at it.

I don't see why an exception couldn't be added for the events coming from the arrow-key navigation. Or maybe only trigger the focus on click interactions on terms.

However, the existing implementation for left/right arrow key navigation doesn't for me because of the dictionary I mentioned. The dictionary steals focus regardless, so that may not be a great solution either.

[Jayanth-Parthsarathy]

This issue does cause me a fair amount of annoyance, so I'd like to take a look at it, unless @Jayanth-Parthsarathy wants to keep hacking at it.

I don't see why an exception couldn't be added for the events coming from the arrow-key navigation. Or maybe only trigger the focus on click interactions on terms.

However, the existing implementation for left/right arrow key navigation doesn't for me because of the dictionary I mentioned. The dictionary steals focus regardless, so that may not be a great solution either.

Sure, you can take this up. Good luck 😄