Project

General

Profile

Actions

action #50399

closed

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
2019-04-15
Due date:
% Done:

0%

Estimated time:
Difficulty:

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 1 (0 open1 closed)

Related to openQA Tests - action #50066: [functional][y] select_console fails to log-in as root Rejectedriafarov2019-04-05

Actions
Actions #1

Updated by SLindoMansilla over 5 years 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.

Actions #2

Updated by riafarov over 5 years 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.

Actions #3

Updated by riafarov over 5 years ago

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

Updated by riafarov over 5 years 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.

Actions #5

Updated by okurz over 5 years 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

Actions #6

Updated by riafarov over 5 years 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.

Actions #7

Updated by riafarov over 5 years ago

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

Actions #8

Updated by riafarov over 5 years 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).

Actions #9

Updated by coolo over 5 years 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

Actions #10

Updated by riafarov over 5 years ago

  • Project changed from openQA Tests to 46
  • 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!

Actions #11

Updated by riafarov over 5 years ago

  • Project changed from 46 to openQA Tests
  • Category set to Bugs in existing tests
Actions #12

Updated by SLindoMansilla over 5 years ago

  • Parent task set to #55703
Actions #13

Updated by okurz about 5 years 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

Actions #14

Updated by okurz about 5 years 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

Actions #15

Updated by okurz about 5 years 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
Actions #16

Updated by okurz about 5 years 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
Actions #17

Updated by okurz about 5 years 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
Actions #18

Updated by SLindoMansilla about 5 years 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.

Actions #19

Updated by okurz almost 5 years 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
Actions #20

Updated by okurz almost 5 years 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
Actions #21

Updated by okurz almost 5 years 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).

Actions #22

Updated by riafarov almost 5 years ago

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

Updated by riafarov over 4 years ago

  • Blocks deleted (action #61832: [functional][y] autoyast: re-enable yast2_firstboot test in TW once typing issue is resolved)
Actions #24

Updated by riafarov over 4 years ago

  • Status changed from New to Closed
  • Assignee set to riafarov

I believe that this issue is gone now. Let's resolve and see if there are still any references to it.

Actions

Also available in: Atom PDF