action #21048
closed
[qam] test fails in tracker_search_in_nautilus - keyboard press is not reaching target
Added by pcervinka over 7 years ago.
Updated over 7 years ago.
Category:
Bugs in existing tests
Description
Observation¶
openQA test in scenario sle-12-SP2-Desktop-DVD-Updates-x86_64-qam-regression-other@64bit fails in
tracker_search_in_nautilus
Reproducible¶
Fails since (at least) Build 20170801-1
Expected result¶
Last good: 20170731-1 (or more recent)
Further details¶
Always latest result in this scenario: latest
CTRL-F should be sent to "nautilus", followed by search string "newfile" and "ret", but
nothing reach application and gedit doesn't start.
09:24:56.1817 39240 <<< testapi::wait_screen_change(timeout=10)
09:24:56.1823 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/tracker/tracker_search_in_nautilus.pm:20 called testapi::send_key
09:24:56.1823 39240 <<< testapi::send_key(key='ctrl-f')
09:24:56.3931 39240 waiting for screen change: 0 1000000
09:24:56.8968 39240 waiting for screen change: 0 20.8163729787519
09:24:56.8969 39240 >>> testapi::wait_screen_change: screen change seen at 0
09:24:56.8970 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/tracker/tracker_search_in_nautilus.pm:21 called testapi::type_string
09:24:56.8971 39240 <<< testapi::type_string(string='newfile', max_interval=250, wait_screen_changes=0)
09:24:57.0686 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/tracker/tracker_search_in_nautilus.pm:22 called testapi::send_key
09:24:57.0688 39240 <<< testapi::send_key(key='ret')
09:24:57.2739 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/tracker/tracker_search_in_nautilus.pm:23 called testapi::assert_screen
09:24:57.2740 39240 <<< testapi::assert_screen(mustmatch='gedit-launched', timeout=3)
09:24:57.2870 39242 MATCH(gedit-launched-20160713:0.00)
09:24:57.3003 39242 MATCH(gedit-launched-20150512:0.0
- Related to action #5830: Get rid of wait_idle to improve performance on !qemu added
Same behavior applies also for shotwell failure, ALT-R doesn't reach application
https://openqa.suse.de/tests/1087881#step/shotwell_edit/21
17:05:48.5317 23575 MATCH(shotwell_edit-shotwell-remove-prompt-20160726:1.00)
17:05:48.6104 23572 >>> testapi::_handle_found_needle: found shotwell_edit-shotwell-remove-prompt-20160726, similarity 1.00 @ 256/278
17:05:48.6105 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/shotwell/shotwell_edit.pm:41 called testapi::wait_screen_change
17:05:48.6106 23572 <<< testapi::wait_screen_change(timeout=10)
17:05:48.6115 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/shotwell/shotwell_edit.pm:41 called testapi::send_key
17:05:48.6115 23572 <<< testapi::send_key(key='alt-r')
17:05:48.8206 23572 waiting for screen change: 0 42.8989341273647
17:05:48.8207 23572 >>> testapi::wait_screen_change: screen change seen at 0
17:05:48.8208 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/shotwell/shotwell_edit.pm:42 called testapi::send_key
17:05:48.8209 23572 <<< testapi::send_key(key='esc')
17:05:49.0269 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/shotwell/shotwell_edit.pm:43 called testapi::wait_still_screen
17:05:49.0271 23572 <<< testapi::wait_still_screen(stilltime=7, timeout=30, simlvl=47)
17:05:56.5888 23572 >>> testapi::wait_still_screen: detected same image for 7 seconds
17:05:56.5890 Debug: /var/lib/openqa/cache/tests/sle/tests/x11regressions/shotwell/shotwell_edit.pm:44 called testapi::assert_screen
17:05:56.5891 23572 <<< testapi::assert_screen(mustmatch='shotwell-removed-picture', timeout=30)
17:05:56.6104 23575 MATCH(shotwell_edit-shotwell-removed-picture-20160510:0.00)
I believe it is related, because these multiple test failures just started when changes in #5830 were implemented.
There is another test which fails with strange result, desktop_mainmenu:
https://openqa.suse.de/tests/1089639#step/desktop_mainmenu/2
ALT-F1 is send without any synchronization and incorrect menu is displayed.
I verified behavior on installation in VM and Gnome shortcut works as expected, it is not a product bug.
pcervinka wrote:
Unstable keyboard inputs cause failures in gnote_search_body and gnote_search_title.
gnote_search_body: https://openqa.suse.de/tests/1088709#step/gnote_search_body/8
send_key "ret";
send_key "ctrl-f";
type_string "and";
gnote_search_title: https://openqa.suse.de/tests/1088709#step/gnote_search_title/8
send_key "ret";
send_key "ctrl-f";
type_string "here";
GNOTE only:
I was able to reproduce this on gnote in my laptop using my fingers.
I only tested this with gnote. I don't know about other apps.
On gnote the problem is that the interface is "slow". If we do ctrl-f and imediatly start writing we can see that the first letters will go to the text body and the last letters will go to the search field.
This test needs a sleep between the sending of the return key and the start of the writing.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: qam-regression-other
https://openqa.suse.de/tests/1132480
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: qam-regression-other
https://openqa.suse.de/tests/1158952
- Status changed from New to In Progress
- Assignee set to pcervinka
- % Done changed from 0 to 60
Reproduced issue with shotwell_edit:
wait_screen_change { send_key 'alt-r' };
send_key "esc";
If is esc key pressed fast, it will cancel image removal.
The issue with tracker_search_in_nautilus is in the line:
wait_screen_change { type_string 'newfile' };
Nautilus searches for string during typing, it means that each typed character can generate screen change and string is typed partially (not complete like: n,ne,newf).
empathy_aim issue is caused by lines:
wait_screen_change { send_key "alt-r" };
send_key "alt-c";
If alt-c is pressed very fast, it will cancel account removal.
- % Done changed from 60 to 90
Fixes for shotwell_edit,tracker_search_in_nautilus,empathy_aim, evolution_meeting_imap were merged.
gnote_search_* and desktop_mainmenu issues didn't occur for some time.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF