[tools][zkvm] test fails to rightclick in reboot_gnome
openQA test in scenario sle-12-SP3-Server-DVD-s390x-gnome@zkvm fails in
It fails because of missing the right click to show the password.
Not sure if poo#10642 or poo#12758 since they are closed for quiet some time now.
Fails since (at least) Build 0293
Last good: 0290 (or more recent)
Always latest result in this scenario: latest
#3 Updated by asmorodskyi almost 5 years ago
- Subject changed from test fails to rightclick in reboot_gnome to [s390][tools] test fails to rightclick in reboot_gnome
- Priority changed from Normal to High
https://openqa.suse.de/tests/846139#step/reboot_gnome/7 - another example , most probably issue related to s390 and how we interact with SUT there
#4 Updated by asmorodskyi almost 5 years ago
- Subject changed from [s390][tools] test fails to rightclick in reboot_gnome to [tools] test fails to rightclick in reboot_gnome
assumption regarding that issue related only to s390 was wrong .
We have exactly same behavior on x86 https://openqa.suse.de/tests/855282
#5 Updated by okurz almost 5 years ago
checking the video in https://openqa.suse.de/tests/855282/file/video.ogv I can see that there is a mouse click appearing but no context menue appears. product bug?
#6 Updated by okurz almost 5 years ago
Checking the zkvm video I can see the context menue appearing for a split second but disappearing again.
what I see in the logfile:
22:03:49.0514 22531 <<< testapi::assert_and_click(mustmatch='reboot-auth-typed', button='right', timeout=30) 22:03:49.0515 22531 clicking at 496/397 22:03:49.0515 Debug: /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/reboot_gnome.pm:32 called testapi::assert_and_click 22:03:49.0516 22531 <<< testapi::mouse_set(x=496, y=397) 22:03:49.0519 22532 mouse_move 496, 397 22:03:49.0519 22532 send_pointer_event 0, 496, 397, 0 22:03:49.0521 Debug: /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/reboot_gnome.pm:32 called testapi::assert_and_click 22:03:49.0522 22531 <<< testapi::mouse_click(button='right', cursor_down='0.15') 22:03:49.0525 22532 pointer_event 4 496, 397 22:03:49.0525 22532 send_pointer_event 4, 496, 397, 0 22:03:49.2032 22532 pointer_event 0 496, 397 22:03:49.2033 22532 send_pointer_event 0, 496, 397, 0 2017-03-30T18:03:50.748499-04:00 linux-gq6t gnome-session-binary: GLib-GObject-CRITICAL: g_object_unref: assertion 'G_IS_OBJECT (object)' failed 22:03:50.2037 Debug: /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/reboot_gnome.pm:32 called testapi::assert_and_click 22:03:50.2039 22531 <<< testapi::mouse_set(x=1023, y=767) 22:03:50.2044 22532 mouse_move 1023, 767 22:03:50.2045 22532 send_pointer_event 0, 1023, 767, 0 waiting for screen change: 0 44.6105184107468 22:03:50.2134 22531 >>> testapi::wait_screen_change: screen change seen at 0 22:03:50.2135 Debug: /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/reboot_gnome.pm:37 called testapi::wait_screen_change 22:03:50.2136 22531 <<< testapi::wait_screen_change(timeout=10) 22:03:50.2141 Debug: /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/reboot_gnome.pm:36 called testapi::assert_and_click 22:03:50.2142 22531 <<< testapi::assert_screen(mustmatch='reboot-auth-showtext', timeout=30)
I diffed that with the "last good" and all the "pointer_event" and "mouse_move" have exactly the same content. Only timestamps differ and therefore potentially relative time between them.
Could it be that we are sending the down/up events too fast here?
#14 Updated by riafarov over 4 years ago
- Status changed from New to Rejected
Issue cannot be observed for last 2 months for original tcs and happens sporadically migration_offline_sle12sp2-allpatterns_fullupdate. Last occurrence 1 month ago. No logs available.
Probably fixed by wrapping right click into "wait_screen_change" in https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/265658e3ce269edfc3da18d8ea539b940f65c0c7
Reopen in case appears again.