Project

General

Profile

action #110473

System role cannot be selected in a remote vnc installation in Tumbleweed due to graphical issues

Added by dimstar about 1 year ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
JERiveraMoya
Target version:
Current
Start date:
2022-04-29
Due date:
% Done:

0%

Estimated time:

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.

Related issues

Related to qe-yam - action #112775: Resurrect supportserver_generator_from_hdd_gnome in TumbleweedResolved2022-06-21

History

#1 Updated by dimstar about 1 year 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'

#2 Updated by szarate about 1 year ago

I wonder if something like repeating the action until it matches a max of 3 times is a good solution.

#3 Updated by maritawerner about 1 year ago

  • Project changed from openQA Tests to qe-yam
  • Category deleted (Bugs in existing tests)

JERiveraMoya, I assign the ticket to the yast team.

#4 Updated by favogt about 1 year 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.

#5 Updated by JERiveraMoya about 1 year 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.

#6 Updated by JERiveraMoya about 1 year ago

  • Description updated (diff)
  • Priority changed from Normal to High

#7 Updated by JERiveraMoya about 1 year ago

  • Tags deleted (qe-yast-refinement)
  • Description updated (diff)
  • Status changed from New to Workable

#8 Updated by geor about 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to geor

#9 Updated by geor about 1 year ago

  • Status changed from In Progress to Workable
  • Assignee deleted (geor)

#10 Updated by JERiveraMoya about 1 year ago

  • Status changed from Workable to Blocked

#11 Updated by JERiveraMoya 12 months 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.

#12 Updated by JERiveraMoya 12 months ago

  • Related to action #112775: Resurrect supportserver_generator_from_hdd_gnome in Tumbleweed added

#13 Updated by openqa_review 11 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
https://openqa.opensuse.org/tests/2449970#step/remote_target/1

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" or "EOL" (End-of-Life)
  3. 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.

#14 Updated by okurz 11 months 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?

#15 Updated by JERiveraMoya 11 months 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.

#16 Updated by openqa_review 10 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
https://openqa.opensuse.org/tests/2493816#step/remote_target/1

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" or "EOL" (End-of-Life)
  3. 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.

Also available in: Atom PDF