action #50399
closedopenQA 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 about 4 years ago.
0%
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
Updated by SLindoMansilla about 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.
Updated by riafarov about 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.
Updated by riafarov about 5 years ago
- Related to action #50066: [functional][y] select_console fails to log-in as root added
Updated by riafarov about 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.
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: gnome+proxy_SCC+allmodules
https://openqa.suse.de/tests/2874447
Updated by riafarov about 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.
Updated by riafarov about 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.
Updated by riafarov about 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).
Updated by coolo about 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
Updated by riafarov about 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!
Updated by riafarov almost 5 years ago
- Project changed from 46 to openQA Tests
- Category set to Bugs in existing tests
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: lvm-full-encrypt
https://openqa.suse.de/tests/3340515
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/1041163
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_controller
https://openqa.suse.de/tests/3454958
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 4 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:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 4 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:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by SLindoMansilla over 4 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.
Updated by okurz over 4 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:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 4 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:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 4 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).
Updated by riafarov over 4 years ago
- Blocks action #61832: [functional][y] autoyast: re-enable yast2_firstboot test in TW once typing issue is resolved added
Updated by riafarov about 4 years ago
- Blocks deleted (action #61832: [functional][y] autoyast: re-enable yast2_firstboot test in TW once typing issue is resolved)
Updated by riafarov about 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.