1687328 - Unable to navigate fields with Tab key

Status: RESOLVED FIXED

(Webtools Graveyard :: Pontoon, defect, P2)

Description

[Eduardo Trápani]

When I try to move between fields using tab, Pontoon overwrites the translation I just typed with another possible suggestion from Machinery. No warning or anything, just an overwrite of a fine translation that you cannot recover.

In my opinion that really breaks the Tab functionality one expects in a site.

But for me the actual problem is that it heavily impacts accessibility because it is no longer possible to move the focus between fields using tab and I have to use the mouse a lot more (which takes a much longer time for me to do). I'm not sure how a blind user would do that either, how to leave a, say FTL field to go to the next.

Could that behaviour be configurable? Is there a way to turn it off?

Comment 1

[Matjaz Horvat [:mathjazz]]

That's a good point. I assume it's especially annoying in a multi-value Fluent string.

I can think of Option (Alt) + Tab to be used as a shortcut instead of just Tab.

I also wonder what Julen proposes.

Comment 2

[Matjaz Horvat [:mathjazz]]

Attachment: GitHub Pull Request

Comment 3

[Julen Ruiz Aizpuru]

FTR, the sole reason to use Tab in the current implementation is purely because that key was already being used in the older incarnation of the editor. So I didn't want to break backwards-compatibility (if you can call it that way) when bringing back the feature. That said, I agree with Eduardo's points — especially now that multi-value Fluent strings are present as you point out Matjaz.

I haven't used Windows in a while, but I can see Alt+Tab possibly causing trouble because it triggers the task switcher, so maybe it's not the best choice. Let me elaborate on other options in a separate comment.

Comment 4

[Julen Ruiz Aizpuru]

As a heavy keyboard and Machinery user, for me it's important this shortcut is readily available and has as less typing friction as possible. In Mac, I could see myself using a combination of Cmd+<key>, but there will always be trade-offs to consider. Here's a list of possible combinations:

• Cmd+Space — Pros: easy to type. Cons: Would hijack Spotlight
• Cmd+j/k — Pros: easy to type. j/k are widely used for up/down navigation, which can map well to selecting next/prev Machinery results. Cons: It'd hijack hiding the window and focusing the search box (in Firefox)
• Cmd+/ — Pros: easy to type (in en keyboard layouts). Cons: Needs same finger as the Enter key, which makes it more difficult to type that next. / is not easy/possible to type in all keyboard layouts

I don't have a strong preference right off the bat, and I believe I'd need some exposure time to better understand how these shortcuts perform.

Comment 5

[Julen Ruiz Aizpuru]

For the originally reported issue at hand, a possible way forward could be to immediately move away from the Tab keyboard shortcut to an interim value, and leave it undocumented in the UI until a permanent solution is agreed upon.

Comment 6

[Matjaz Horvat [:mathjazz]]

Since there are so many keyboard layouts, operating systems and browsers, it's hard to find shortcuts that aren't clashing with any of the established ones and are still easy to use. IMHO Tab, and keyboard shortcuts for Task switcher on Windows, Spotlight on Mac and focusing the search box in Firefox all fall into this group, some more than other.

I believe the right solution here is to first find a more or less unique shortcut, even if it's a bit less handy, and then fix bug 1355835.

I've found an option with the Ctrl + Shift combination, which we use with several other shortcuts:

• Copy next helper: Ctrl + Shift + ↓
• Copy previous helper: Ctrl + Shift + ↑

We could also make sure that Alt is not pressed to avoid the clash with GNOME:
https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts#Window_management

Comment 7

[Julen Ruiz Aizpuru]

Sounds good to me.