Afghani keyboard selected in Greeter if typing fast
For weeks now, I’ve been trying to understand why I sometimes get an Afghani keyboard in Greeter instead of a Spanish one. I think that this sequence reproduce this bug if performed fast enough:
- Press Alt+K to change the keyboard layout.
- Type “spa” fast enough and press Enter right after that.
- Afghani keyboard is selected instead of Spanish.
If I perform the same sequence slower I get a Spanish keyboard as expected.
#1 Updated by intrigeri 2017-05-25 18:01:44
- Status changed from New to Confirmed
- Parent task set to
(Please don’t rely too much on the fact that I read all Redmine changes: I’m not the only one responsible for the new Greeter and the port to Stretch => adding anonym and alan as watchers.)
#2 Updated by intrigeri 2017-05-25 18:17:41
- Assignee set to sajolida
- Target version deleted (
- QA Check set to Info Needed
I wonder if this happens only because Afghani is the first item on the list, or because the “sp” is typed before the GTK widget is ready to take keystrokes into account and thus the first item that matches the next letter typed (“a”) is picked. I can’t reproduce this myself, but it would be interesting to know if Afghani is selected as well if you type “fre” (that has no “a”) very fast (instead of “spa”) => info needed. This will allow whoever tackles this to focus their work better :)
There’s surely a bug somewhere: maybe the GTK widget gets the focus too late, maybe we’re building the list of keyboards lazily when “Keyboard Layout” is selected and there’s some lag, or something.
But I don’t think we can realistically set this as a blocker for 3.0, for three reasons:
- I doubt it’s a regression as using the keyboard only was really painful in the old Greeter;
- we have a bunch of higher-priority Greeter bugs to work on (Alan and I have scheduled two days for that);
- I’m sorry but most GUI software we ship in Tails tends to need a little bit of time here and there between user actions. This is one of the (design) reasons why they provide visual feedback wrt. their current status and the outcome of user actions. In the case at hand, this implies that typing Enter super fast, without checking that the desired item was selected already, i.e. using a GUI without looking at the outcome of one’s actions, is deemed to produce unexpected results. Your CPU simply needs some time to react to your keystrokes, and that’s not we we can fix in the next 2 weeks :)
=> dropping the target version.
#3 Updated by sajolida 2017-05-26 13:14:28
- Assignee changed from sajolida to alant
- QA Check deleted (
- The bug occurs only when “Enter” is typed very fast after “spa”. Pausing for 1 second between “Alt+K” and “spa” doesn’t prevent the bug.
- Even when the bug appears, “Spanish” is highlighted in the search box results before pressing “Enter”. So there’s a mismatch between the feedback given by the search box (“Spanish is selected”) and the outcome (“Afghani is selected”).
- If typing again “Alk+K” right after the bug occurs, “spa” is still typed in the search box and press “Enter” selects Spanish as expected. That’s a workaround :)
- Performing the same sequence with “fre” also leads to Afghani being selected.
- I can reproduce this bug as many time as I want from the same session, switch Afghani back to English or some other keyboard layout that I know how to use.
It seems like you’ve felt pressured by my setting 3.0, it was not my intention to say that this should be fixed in time for 3.0 as I agree that it’s a minor glitch.
I disagree with your analysis of what feedback is useful for but I won’t go into a theoretical UX discussion here :)
Assigning to alant who wrote that software because otherwise with no assignee and no target version I’m afraid we will loose this from sight.