Bug #7912

Non-US keyboard layout selected with Greeter sometimes is not active when logged in

Added by emmapeel 2014-09-18 00:26:15 . Updated 2020-04-15 06:05:41 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
Category:
Target version:
Tails_2.0
Start date:
2014-11-23
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
0
Affected tool:
Welcome Screen
Deliverable for:

Description

Reported by two users, happening from Tails 1.1

Steps to reproduce:

- Choose a different keyboard layout at boot (not language).

Error:

- Not always, but sometimes the layout active when logged in is English. Keyboard layout is present on the top bar, so you can activate your desired layout clicking on it.

Desired result:

- Always have the chosen keyboard layout active when logged.

Subtasks

Related issues

Related to Tails - Bug #7065: Selected non-US keyboard layout is not applied Resolved 2014-04-11
Related to Tails - Feature #8713: Consider replacing some of our code with the GDM->GNOME session keyboard layout passthrough Resolved 2015-01-16
Related to Tails - Bug #9336: Document in known issues the workaround for wrong keyboard layout being selected Resolved 2015-05-04

History

#1 Updated by intrigeri 2014-09-22 12:42:45

  • Assignee set to emmapeel
  • QA Check set to Info Needed

We need a full bug report (including the greeter’s log) to be able to do anything about it.

#2 Updated by intrigeri 2014-10-09 05:54:55

  • Subject changed from Keyboard layout selected with Greeter sometimes is not active when logged in to Non-US keyboard layout selected with Greeter sometimes is not active when logged in
  • Status changed from New to Confirmed
  • Assignee deleted (emmapeel)
  • Priority changed from Normal to Elevated
  • Target version set to Tails_1.2.1
  • QA Check deleted (Info Needed)

Reproduced, and suddenly a few people tell me they see it too sometimes. I guess it’s the same bug (Bug #7065) that I workaround’ed in commit af105fb90a, and that was reintroduced with cc4e759e0. That’s a regression against Tails/Squeeze => raising priority, and tentatively flagging for 1.2.1.

#3 Updated by intrigeri 2014-10-09 05:55:12

  • related to Bug #7065: Selected non-US keyboard layout is not applied added

#4 Updated by sajolida 2014-10-11 01:38:54

This bug was first described publicly on tails-l10n in August:

https://mailman.boum.org/pipermail/tails-l10n/2014-August/001458.html

#5 Updated by intrigeri 2014-11-10 16:29:12

  • Type of work changed from Test to Discuss

Proposed (on -dev@) to drop the alternate US keyboard layout.

#6 Updated by intrigeri 2014-11-23 18:43:16

  • Target version changed from Tails_1.2.1 to Tails_1.3

In the “Dropping the alternate US keyboard layout?” thread, until we have a proper solution, the best mitigation we’ve found is to add the alternate US keyboard layout if, and only if, the chosen layout is not latin-based. So, next step is Feature #8294. Too involved for a late merge for 1.2.1, so postponing.

#7 Updated by intrigeri 2014-12-16 21:33:08

  • Type of work changed from Discuss to Code

For now, it seems that we’ve found a consensus, so let’s tentatively call this a code ticket until we get the results from Feature #8294. And then, possibly we’ll want to discuss it again.

#8 Updated by intrigeri 2015-01-16 15:38:29

  • related to Feature #8713: Consider replacing some of our code with the GDM->GNOME session keyboard layout passthrough added

#9 Updated by BitingBird 2015-02-23 02:00:40

No work has been done on this one: should it be postponed to 1.3.1, or to 1.4, or the milestone removed altogether since nobody is assigned ?

#10 Updated by intrigeri 2015-02-23 12:02:27

> No work has been done on this one: should it be postponed to 1.3.1, or to 1.4, or the milestone removed altogether since nobody is assigned ?

Raised the general underlying question on -dev@.

#11 Updated by BitingBird 2015-03-12 21:02:47

  • Target version changed from Tails_1.3 to Tails_1.3.2

Finally moving to next milestone. Let’s hope someone adopts this lonely ticket :)

#12 Updated by intrigeri 2015-03-20 23:27:42

  • Assignee set to alant
  • QA Check set to Info Needed

Alan told me he can reproduce this bug quite reliably. Alan, can you please try to reproduce it on Tails/Jessie?

This could help us assert how urgent it is to fix this problem (ideally we would “just” fix it, but so far everyone agrees we should, and nobody started working on it nor on the easier short-term workaround (Feature #8294) we’ve agreed about, so I feel the need to be a bit more pragmatic here).

#13 Updated by alant 2015-03-22 16:09:20

  • Assignee deleted (alant)

I tried to reproduce the issue on three machines that I’ve seen showing this bug regularly. I wasn’t able to reproduce it with Tails/Jessie but not with 1.3 either. I tried at least two times par machine. It is possible something got fixed since 1.2?

#14 Updated by kytv 2015-03-22 20:58:57

I just saw this with 1.3.

#15 Updated by BitingBird 2015-03-22 22:01:31

Just saw it while testing 1.3.1 (testing farsi -> started with en default keyboard, clicking on it enables fa).

#16 Updated by intrigeri 2015-03-23 15:07:27

  • Assignee set to kytv

kytv wrote:
> I just saw this with 1.3.

“Cool” => same question as the one I asked Alan, then: can you reproduce on Tails/Jessie?

#17 Updated by kytv 2015-03-24 21:57:58

intrigeri wrote:
> kytv wrote:
> > I just saw this with 1.3.
>
> “Cool” => same question as the one I asked Alan, then: can you reproduce on Tails/Jessie?

Due to Bug #8778 I hadn’t done much with Jessie. Now that I run the test suite (woohoo), maybe I can use a custom, not-to-be-checked-in scenario to find out.

To be determined, though it may take a while.

#18 Updated by alant 2015-03-31 19:21:47

kytv wrote:
> I just saw this with 1.3.

I also saw this when testing 1.3.2, then tried to start Tails/Jessie the same way and wasn’t able to reproduce the issue. But this doesn’t look very deterministic to me…

#19 Updated by BitingBird 2015-04-06 21:13:56

  • Target version changed from Tails_1.3.2 to Tails_1.4

Postponing

#20 Updated by kytv 2015-04-27 15:37:02

  • Status changed from Confirmed to In Progress

Working on creating test suite scenarios to test whether this is a problem in Jessie.
_
(Note that when I have changed the keyboard before I’ve only changed the keyboard layout; I don’t know if this is reproducible when changing the location or language options)._

#21 Updated by kytv 2015-04-28 11:43:51

  • Assignee changed from kytv to intrigeri
  • QA Check deleted (Info Needed)

I created a scenario to automate the steps that I’ve taken when I’ve seen en_US activated after login even though I I selected a non-US keyboard layout at the greeter in Wheezy.

The last test session’s results:

  Scenario: keyboard layout test                  # features/kblayout.feature:206
    Given a computer                              # features/step_definitions/common_steps.rb:66
    And I boot Tails                              # features/step_definitions/kb.rb:6
    And I change the keyboard settings and login  # features/step_definitions/kb.rb:13
    Then the correct keyboard layout is set       # features/step_definitions/kb.rb:25

90 scenarios (90 passed)
360 steps (360 passed)
366m11.649s

I ran scenario a few more times without a single failure. I don’t know that we can say it is absolutely not a problem in Jessie, but I could not reproduce it after more than 270 boots & logins.

#22 Updated by intrigeri 2015-04-29 07:59:22

  • Assignee changed from intrigeri to kytv

kytv wrote:
> I ran scenario a few more times without a single failure. I don’t know that we can say it is absolutely not a problem in Jessie, but I could not reproduce it after more than 270 boots & logins.

Cool, thanks. Now, that’s useful only if you can reproduce the bug in Tails/Wheezy with the same scenario, right? (I’ve of course never seen it with the automated test suite, since we don’t test non-en_US keyboard layouts in there yet.)

#23 Updated by kytv 2015-05-01 11:30:55

intrigeri wrote:
> kytv wrote:
> > I ran scenario a few more times without a single failure. I don’t know that we can say it is absolutely not a problem in Jessie, but I could not reproduce it after more than 270 boots & logins.
>
> Cool, thanks. Now, that’s useful only if you can reproduce the bug in Tails/Wheezy with the same scenario, right? (I’ve of course never seen it with the automated test suite, since we don’t test non-en_US keyboard layouts in there yet.)

I think that’s mostly correct, though conclusively proving a negative can be difficult. I ran a modified version (updating the images to match what is found in Wheezy) and it too had no failures. :(

I made some modifications and was able to reproduce this failure to set the keyboard in Wheezy. The key seems to be hesitating before pressing the login button.

#24 Updated by intrigeri 2015-05-01 11:39:09

> I made some modifications and was able to reproduce this failure to set the keyboard in Wheezy. The key seems to be hesitating before pressing the login button.

Please do publish these modifications :)

#25 Updated by kytv 2015-05-02 03:36:06

intrigeri wrote:
> > I made some modifications and was able to reproduce this failure to set the keyboard in Wheezy. The key seems to be hesitating before pressing the login button.
>
> Please do publish these modifications :)

(This would be much tidier if I intended to check it in. Indeed, this is the epitome of “quick ‘n’ dirty”.)

My kb.rb contains

Then /^I see the greeter window$/ do
  next if @skip_steps_while_restoring_background
  @screen.wait("TailsGreeterLoginButton.png", 120)
end

Then /^I boot Tails$/ do
  next if @skip_steps_while_restoring_background
  step 'the network is plugged'
  step 'I start the computer'
  step 'the computer boots Tails'
  step 'I see the greeter window'
  step 'I enable more Tails Greeter options'
  step 'I set sudo password "asdf"'
end

Then /^I change the keyboard settings and login$/ do
  next if @skip_steps_while_restoring_background
  @screen.wait_and_click("KBEnglish.png", 120)
  @screen.type(Sikuli::Key.PAGE_DOWN)
  @screen.wait_and_click("KBOther.png", 120)
  @screen.wait("Language.png", 120)
  @screen.type("germ" + Sikuli::Key.ENTER)
  @screen.wait_and_click("Apply.png", 60) 
  step 'I wait between 15 and 80 seconds'
  step 'I log in to a new session'
  step 'GNOME has started'
end

Then /^the correct keyboard layout is set$/ do
  next if @skip_steps_while_restoring_background
  @screen.wait('ExpectedSelected.png', 15) 
end

My feature (repeated until there are 270 scenarios):

@product
Feature: Various checks

  Background:
    Given a computer
    And I boot Tails
    And I save the state so the background can be restored next scenario

  Scenario: keyboard test 
    Then I change the keyboard settings and login
    And the correct keyboard layout is set

I left this running overnight in Jessie. Results:

270 scenarios (270 passed)
1350 steps (1350 passed)
364m33.546s

(More scenarios run in less time. Yay optimizations and ‘bare metal’.)

I’m re-running it in Wheezy. I already know I’ll see the failures but I’ll leave it running because I’m curious as to how many failures I’ll see.

    Then I change the keyboard settings and login                        # features/step_definitions/kb.rb:16
      Slept for 58 seconds
    And the correct keyboard layout is set                               # features/step_definitions/kb.rb:29
      FindFailed: can not find ExpectedSelected.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/k.feature:15:in `And the correct keyboard layout is set'

So

  • this is absolutely a problem in 1.3.2; and
  • it is likely that this is not a problem in feature/jessie.

#26 Updated by kytv 2015-05-02 09:44:25

  • Assignee changed from kytv to intrigeri

Final results against 1.3.2:

270 scenarios (97 failed, 173 passed)
1350 steps (97 failed, 1 skipped, 1252 passed)
373m27.563s

Log attached, maybe it’ll be as interesting for others as it was to me. Note, again, that without the sleep:s it passed every time.

Re-assigning to intrigeri since I think I’ve done my part in demonstrating it is a problem in Wheezy but it doesn’t seem to be a problem in feature/jessie.

#27 Updated by intrigeri 2015-05-02 12:13:15

  • Type of work changed from Code to Discuss

Given:

  • all this info and test results (thanks!)
  • no progress was made on Feature #8294 since we decided it was the way to go 5 months ago (Bug #7912#note-6)
  • Tails/Jessie is getting closer

=> I’m tempted to simply flag this as resolved in the 4.0 milestone, and add it to known issues for Wheezy (along with the trivial workaround when it happens) if it’s not there yet.

#28 Updated by BitingBird 2015-05-02 12:39:26

Seems a good call to me. Let’s work on making Tails Jessie happen instead of fixing Tails wheezy occasional bugs.

#29 Updated by kytv 2015-05-02 14:13:25

intrigeri wrote:
> => I’m tempted to simply flag this as resolved in the 4.0 milestone, and add it to known issues for Wheezy (along with the trivial workaround when it happens) if it’s not there yet.

BitingBird wrote:
> Seems a good call to me. Let’s work on making Tails Jessie happen instead of fixing Tails wheezy occasional bugs.

I agree wholeheartedly. This is a very minor issue and if it is fixed in Jessie as my testing seems to suggest, “resolved in 4.0” sounds good to me.

It’d be different if this happened every time or if the keyboard selection at the greeter didn’t do anything. Since it is added as an alternate keyboard layout which can be selected by clicking the En button in the systray and it appears that the update to Jessie in a few months will automatically resolve it, I personally think that the time tracking down and fixing the race condition would be better spent doing almost anything else.

#30 Updated by intrigeri 2015-05-04 04:48:39

  • related to Bug #9336: Document in known issues the workaround for wrong keyboard layout being selected added

#31 Updated by intrigeri 2015-05-04 04:50:42

  • Status changed from In Progress to Resolved
  • Target version changed from Tails_1.4 to Tails_2.0

At the monthly meeting we decided: this bug has an easy workaround, it seems that it doesn’t affect Tails/Jessie, and it doesn’t seem easy to fix. So we decided to simply flag it as resolved in the 4.0 milestone, and add it to known issues for Wheezy (along with the trivial workaround when it happens) if it’s not there yet. BitingBird will do the latter (Bug #9336).

#32 Updated by intrigeri 2020-04-15 06:05:41

  • Affected tool changed from Greeter to Welcome Screen