action #50399

openQA Project - action #55703: send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly

[functional][y] Installer doesn't react to key press

Added by jorauch 10 months ago. Updated 25 days ago.

Status:NewStart date:15/04/2019
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Bugs in existing tests
Target version:QA - future
Difficulty:
Duration:

Description

Observation

Looks like the alt-n did not reach the SUT, as we are still in the timezone screen.
According to the autoinst-log the key was sent .
This was also seen in 212.1 but in the partitioning module: https://openqa.suse.de/tests/2802128#step/partitioning/2

Reproducible

Fails since Build 213.2
in scenario sle-15-SP1-Installer-DVD-x86_64-gnome+proxy_SCC+allmodules@64bit

Expected result

Last good: 210.1
The installation should be on the next step at this point

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #50066: [functional][y] select_console fails to log-in as root Rejected 05/04/2019
Blocks openQA Tests - action #61832: [functional][y] autoyast: re-enable yast2_firstboot test ... Blocked 07/01/2020

History

#1 Updated by SLindoMansilla 10 months ago

  • Subject changed from test fails in user_settings - looks like alt-n didn't reach the SUT to [functional][y] test fails in user_settings - looks like alt-n didn't reach the SUT
  • Description updated (diff)

As a result of backlog triaging (see https://progress.opensuse.org/projects/openqatests/wiki#ticket-backlog-triaging for more information).

Please, feel free to adjust the category or the "[label]" if you think different.

#2 Updated by riafarov 10 months ago

  • Assignee set to riafarov
  • Priority changed from High to Normal

We still have many issues with lost keys, restarting tests helps, so I lower the priority and we will take a look if can improve anything.

#3 Updated by riafarov 10 months ago

  • Related to action #50066: [functional][y] select_console fails to log-in as root added

#4 Updated by riafarov 10 months ago

  • Subject changed from [functional][y] test fails in user_settings - looks like alt-n didn't reach the SUT to [functional][y] key presses do not reach SUT on qemu
  • Target version changed from Milestone 24 to Milestone 25

We have quite some cases where system doesn't get key presses. Symptoms are same as we have for years now, we can think of workaround.

#5 Updated by okurz 9 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: gnome+proxy_SCC+allmodules
https://openqa.suse.de/tests/2874447

#6 Updated by riafarov 9 months ago

  • Target version changed from Milestone 25 to Milestone 26

it's not like we can do much about it, so using ticket for tracking.

#7 Updated by riafarov 9 months ago

openQA test in scenario sle-12-SP5-Server-MINI-ISO-x86_64-remote_vnc_controller@64bit fails in
accept_license
another affected case.

#8 Updated by riafarov 9 months ago

  • Project changed from openQA Tests to openQA Project
  • Subject changed from [functional][y] key presses do not reach SUT on qemu to key presses do not reach SUT on qemu
  • Category changed from Bugs in existing tests to 132
  • Assignee deleted (riafarov)
  • Target version deleted (Milestone 26)

Moving to the tools team to suggest if there is anything we can do (except workaround and retries).

#9 Updated by coolo 9 months ago

  • Project changed from openQA Project to openQA Tests
  • Subject changed from key presses do not reach SUT on qemu to Installer doesn't react to key press
  • Category deleted (132)

This is in about no case an openQA problem - the kernel or the X layer discard the key or yast is just too slow to react. That the key press doesn't reach the SUT is a theory I strongly object to.

How you want to workaround the product bug is up to the test writers. Last time someone in Yifan's team debugged it (sorry, forgot the name) things pointed to libinput

#10 Updated by riafarov 9 months ago

  • Project changed from openQA Tests to SUSE QA tests
  • Subject changed from Installer doesn't react to key press to [functional][y] Installer doesn't react to key press
  • Target version set to future

coolo wrote:

This is in about no case an openQA problem - the kernel or the X layer discard the key or yast is just too slow to react. That the key press doesn't reach the SUT is a theory I strongly object to.


How you want to workaround the product bug is up to the test writers. Last time someone in Yifan's team debugged it (sorry, forgot the name) things pointed to libinput

That's actually true, we might try using at least more up to date VNC client image we use to send keys over VNC. We'll take a deeper look. Thanks for the feedback!

#11 Updated by riafarov 7 months ago

  • Project changed from SUSE QA tests to openQA Tests
  • Category set to Bugs in existing tests

#12 Updated by SLindoMansilla 6 months ago

  • Parent task set to #55703

#13 Updated by okurz 5 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: lvm-full-encrypt
https://openqa.suse.de/tests/3340515

#14 Updated by okurz 5 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_y2_firstboot
https://openqa.opensuse.org/tests/1041163

#15 Updated by okurz 4 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: remote_vnc_controller
https://openqa.suse.de/tests/3454958

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

#16 Updated by okurz 4 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: remote_vnc_target_nfs
https://openqa.suse.de/tests/3508197

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

#17 Updated by okurz 3 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_y2_firstboot
https://openqa.opensuse.org/tests/1076782

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

#18 Updated by SLindoMansilla 3 months ago

Should be fixed by: https://github.com/os-autoinst/os-autoinst/pull/1260/files

To resolve, provide verification runs, set a proper value for VNC_TYPING_LIMIT if necessary.

#19 Updated by okurz 3 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: remote_vnc_target_nfs
https://openqa.suse.de/tests/3577181

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

#20 Updated by okurz about 1 month ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_y2_firstboot
https://openqa.opensuse.org/tests/1145245

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

#21 Updated by okurz 25 days ago

  • Project changed from openQA Project to openQA Tests
  • Category set to Bugs in existing tests

this is strange. The ticket shows up in "openQA Project" but from the updates it looks like it is in "openQA Tests". Let's see if it works if I move it (again).

#22 Updated by riafarov 14 days ago

  • Blocks action #61832: [functional][y] autoyast: re-enable yast2_firstboot test in TW once typing issue is resolved added

Also available in: Atom PDF