Project

General

Profile

Bug #7912

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

Added by emmapeel over 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/23/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
No
Affected tool:
Greeter

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.


Related issues

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

History

#1 Updated by intrigeri over 5 years ago

  • 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 over 5 years ago

  • 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 (#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 over 5 years ago

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

#4 Updated by sajolida over 5 years ago

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 about 5 years ago

  • Type of work changed from Test to Discuss

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

#6 Updated by intrigeri about 5 years ago

  • 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 #8294. Too involved for a late merge for 1.2.1, so postponing.

#7 Updated by intrigeri about 5 years ago

  • 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 #8294. And then, possibly we'll want to discuss it again.

#8 Updated by intrigeri about 5 years ago

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

#9 Updated by BitingBird almost 5 years ago

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 almost 5 years ago

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 almost 5 years ago

  • 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 almost 5 years ago

  • 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 (#8294) we've agreed about, so I feel the need to be a bit more pragmatic here).

#13 Updated by alant almost 5 years ago

  • 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 almost 5 years ago

I just saw this with 1.3.

#15 Updated by BitingBird almost 5 years ago

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

#16 Updated by intrigeri almost 5 years ago

  • 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 almost 5 years ago

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 #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 almost 5 years ago

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 almost 5 years ago

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

Postponing

#20 Updated by kytv almost 5 years ago

  • 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 almost 5 years ago

  • 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 over 4 years ago

  • 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 over 4 years ago

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 over 4 years ago

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 over 4 years ago

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 over 4 years ago

  • 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 over 4 years ago

  • Type of work changed from Code to Discuss

Given:

  • all this info and test results (thanks!)
  • no progress was made on #8294 since we decided it was the way to go 5 months ago (#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 over 4 years ago

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 over 4 years ago

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 over 4 years ago

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

#31 Updated by intrigeri over 4 years ago

  • 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 (#9336).

Also available in: Atom PDF