action #110473
closedSystem role cannot be selected in a remote vnc installation in Tumbleweed due to graphical issues
0%
Description
Motivation¶
This is a multi-machine test. A server is booted, then a client interacts with the server using vncviewer (tigervnc)
At the role selection, the test is supposed to find the area where to click to select GNOME - this seems to work, but the GNOME desktop role does not get selected, resulting in the test failing.
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-remote_vnc_controller@64bit fails in
system_role
Also to have this fixed will help to move forward this: https://bugzilla.suse.com/show_bug.cgi?id=1197120
Acceptance criteria¶
AC1: Workaround the system role selection
AC2: Workaround shouldn't appear in products where the problem is not present.
Suggestions¶
A retry should help, we should avoid to wait time when there is not re-draw issue.
Updated by dimstar almost 2 years ago
[2022-04-28T19:41:22.566628+02:00] [debug] tests/installation/system_role.pm:69 called system_role::assert_system_role -> tests/installation/system_role.pm:56 called system_role::change_system_role -> tests/installation/system_role.pm:37 called testapi::assert_and_click
[2022-04-28T19:41:22.566824+02:00] [debug] <<< testapi::assert_screen(mustmatch="system-role-gnome", timeout=30)
[2022-04-28T19:41:22.773444+02:00] [debug] >>> testapi::_handle_found_needle: found system-role-gnome-20220223, similarity 1.00 @ 298/229
[2022-04-28T19:41:22.773810+02:00] [debug] tests/installation/system_role.pm:69 called system_role::assert_system_role -> tests/installation/system_role.pm:56 called system_role::change_system_role -> tests/installation/system_role.pm:37 called testapi::assert_and_click
[2022-04-28T19:41:22.774+02:00] [debug] <<< testapi::assert_and_click(mustmatch="system-role-gnome", timeout=30)
[2022-04-28T19:41:22.775485+02:00] [debug] clicking at 303/238
[2022-04-28T19:41:22.775649+02:00] [debug] tests/installation/system_role.pm:69 called system_role::assert_system_role -> tests/installation/system_role.pm:56 called system_role::change_system_role -> tests/installation/system_role.pm:37 called testapi::assert_and_click
[2022-04-28T19:41:22.775754+02:00] [debug] <<< testapi::mouse_set(x=303, y=238)
[2022-04-28T19:41:22.776375+02:00] [debug] mouse_move 303, 238
[2022-04-28T19:41:22.776514+02:00] [debug] send_pointer_event 0, 303, 238, 1
[2022-04-28T19:41:22.777205+02:00] [debug] tests/installation/system_role.pm:69 called system_role::assert_system_role -> tests/installation/system_role.pm:56 called system_role::change_system_role -> tests/installation/system_role.pm:37 called testapi::assert_and_click
[2022-04-28T19:41:22.777376+02:00] [debug] <<< testapi::mouse_click(button="left", cursor_down="0.15")
[2022-04-28T19:41:22.777967+02:00] [debug] pointer_event 1 303, 238
[2022-04-28T19:41:22.778061+02:00] [debug] send_pointer_event 1, 303, 238, 1
[2022-04-28T19:41:22.929299+02:00] [debug] pointer_event 0 303, 238
[2022-04-28T19:41:22.929462+02:00] [debug] send_pointer_event 0, 303, 238, 1
The log looks reasonable so far - it found the needle and identified click coordinates 303/238 - they are bulleteye in the 'radio select' of 'Desktop with GNOME'
Updated by szarate almost 2 years ago
I wonder if something like repeating the action until it matches a max of 3 times is a good solution.
Updated by maritawerner almost 2 years ago
- Project changed from openQA Tests to qe-yam
- Category deleted (
Bugs in existing tests)
@JERiveraMoya, I assign the ticket to the yast team.
Updated by favogt almost 2 years ago
There are obvious graphical issues in the VNC display, e.g. https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=remote_vnc_controller&version=Tumbleweed#step/system_role/3 is missing the bottom part of the transactional system role.
Could be a bug in X, the VNC layers or the client.
Updated by JERiveraMoya almost 2 years ago
- Tags set to qe-yast-refinement
- Subject changed from VNC remote session: click not properly registering(?) to System role cannot be selected in a remote vnc installation in Tumbleweed due to graphical issues
- Target version set to Current
yes, definitively graphical, we try to click when the screen is not ready:
https://bugzilla.opensuse.org/show_bug.cgi?id=1199477
Moving to our backlog and depending on the answer in the bug we can consider a workaround.
Updated by JERiveraMoya almost 2 years ago
- Description updated (diff)
- Priority changed from Normal to High
Updated by JERiveraMoya almost 2 years ago
- Tags deleted (
qe-yast-refinement) - Description updated (diff)
- Status changed from New to Workable
Updated by geor almost 2 years ago
- Status changed from Workable to In Progress
- Assignee set to geor
Updated by geor almost 2 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
geor)
Updated by JERiveraMoya almost 2 years ago
- Status changed from Workable to Blocked
Updated by JERiveraMoya almost 2 years ago
- Assignee set to JERiveraMoya
- Priority changed from High to Normal
So at the end there is not graphical issue, we are using a old image to launch vnc. I created this ticket to remediate this: #112775
As a shortcut I tried manually to update in that qcow2 the package but due to other deps, it fails, so we will need to finish that task to have an updated image.
Updated by JERiveraMoya almost 2 years ago
- Related to action #112775: Resurrect supportserver_generator_from_hdd_gnome in Tumbleweed added
Updated by openqa_review almost 2 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
https://openqa.opensuse.org/tests/2449970#step/remote_target/1
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" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by okurz almost 2 years ago
@JERiveraMoya this is still reproducible in every Tumbleweed snapshot, see https://openqa.opensuse.org/tests/2469813#next_previous. In #110473#note-11 you mentioned a "shortcut" you would try. Any further ideas you have to fix this? Could this be treated with more prio?
Updated by JERiveraMoya almost 2 years ago
- Status changed from Blocked to Closed
Please read https://progress.opensuse.org/issues/110473#note-11.
It is in the top of our queue already, but might take a time, I tried to update the image manually but failed.
I will use that other ticket to not confuse anyone else. I labeled in openQA.
Updated by openqa_review over 1 year 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
https://openqa.opensuse.org/tests/2493816#step/remote_target/1
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" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.