Project

General

Profile

Actions

action #17362

closed

[qam] test fails in pidgin_IRC to accept the 'ret' key from the protocol dialogue - send_key problem

Added by pgeorgiadis about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2017-02-28
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP2-Desktop-DVD-Updates-x86_64-qam-regression-message@64bit fails in
pidgin_IRC

Reproducible

Fails since (at least) Build 20170220-3
It looks like the first occurence since ever or at least a long time.

Expected result

Last good: 20170220-2 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by pgeorgiadis about 7 years ago

Same problem also for pidgin_aim
Link to the test which fails at:

x11_start_program("pidgin");

step

Actions #2

Updated by pgeorgiadis about 7 years ago

firefox_downloading test module fails many times in maintenance for the past 3 months. The latest time is failed here

The error is misleading, because the problem is not the mismatch of the needle.

<<< testapi::assert_screen(mustmatch='firefox-downloading-blank_list', timeout=30)
>>> testapi::_check_backend_response: match=firefox-downloading-blank_list timed out after 30

Expected:

>>> testapi::_handle_found_needle: found firefox-downloading-blank_list-20161111, similarity 1.00 @ 305/139

Actually, the mismatch was expected behavior in that case, because there was an error before that step (24). The error can be found at step 22:

Failed 22 step
Expected 22 step

As you can see from the images, the test should do something like a right click. Looking at the logs, seems like another problem of send_key which was not sent:

12:22:53.4004 885 <<< testapi::send_key(key='shift-f10')

The shift-F10 is the right-click behavior that was not executed on the system. So, I would say this is another problematic candidate for the send_key family of problems.

Actions #3

Updated by pgeorgiadis about 7 years ago

Same problem also with firefox_pdf test in maintenance. The latest problem is related again to the same send_key behavior. Once again, there's a needle mismatch but this not the problem. It is expected to not match because and ESC keystroke should happen earlier, but it didn't:

12:29:54.3542 885 <<< testapi::send_key(key='esc')

As a result, the actual problem starts at step 17, because the Esc key is not pressed, so the PDF is not getting out of the full-screen mode, but it remains in full-screen until the end of the test. Look further:

Problematic step 17
Expected step 17

Actions #4

Updated by pgeorgiadis about 7 years ago

  • Subject changed from test fails in pidgin_IRC to accept the 'ret' key from the protocol dialogue to test fails in pidgin_IRC to accept the 'ret' key from the protocol dialogue - send_key problem
Actions #5

Updated by pgeorgiadis about 7 years ago

Same problem for gnote_rename_title

send_key_until_needlematch 'gnote-new-note-title-matched', 'down', 6;

The needle is not matched because the send_key down was not triggered, so wrong field was selected.

problem 8 step: https://openqa.suse.de/tests/792156#step/gnote_rename_title/8
Expected 8 step: https://openqa.suse.de/tests/791729#step/gnote_rename_title/8

Actions #6

Updated by pluskalm about 7 years ago

  • Assignee set to vsvecova
Actions #7

Updated by pgeorgiadis about 7 years ago

Same happens for firefox_mhtml test. It happened 6 times in the past two months:

Problem in Step 10
Expected in Step 10

What happened:

type_string "file:///dev/shm/ie10.mht\n";

What it should happened:

send_key "alt-d";
type_string "file:///dev/shm/ie10.mht\n";

Once again, the 'send_key' API call was ignored from openQA.

Actions #8

Updated by pgeorgiadis about 7 years ago

Same problem also with gnote_edit_format:

Problematic Step 7
Expected Step 7

What happens is that when the openQA sends send_key "ret"; #back to all notes interface is not actually send (step 6) as a result, the next api call: send_key_until_needlematch 'gnote-new-note-matched', 'down', 6; is doomed to fail, since pressing the 'Down arrow key' makes no impact because the 'Gnote'-window/interface was never selected.

send_key "ret";         #back to all notes interface        <--- this didn't work
send_key_until_needlematch 'gnote-new-note-matched', 'down', 6;
Actions #9

Updated by pgeorgiadis about 7 years ago

Same problem also for gnote_search_title

Problematic Step 6
Expected Step 6

What happened here is that ctrl_f was never sent:

send_key "ctrl-f";
sleep 2;
type_string "here";

As a result, the search for 'here' is not going to happen, so the needle looking for that fails.
This can be also seen from the logs:

12:19:07.0588 2812 <<< testapi::send_key(key='ctrl-f')
12:19:09.2610 Debug: /var/lib/openqa/share/tests/sle/tests/x11regressions/gnote/gnote_search_title.pm:27 called testapi::type_string
12:19:09.2612 2812 <<< testapi::type_string(string='here', max_interval=250, wait_screen_changes=0)
...
12:19:14.7979 2812 >>> testapi::_check_backend_response: match=gnote-search-title-here timed out after 5
12:19:14.8466 2812 test gnote_search_title failed
Actions #10

Updated by pluskalm about 7 years ago

  • Assignee changed from vsvecova to osukup
Actions #11

Updated by pluskalm about 7 years ago

  • Subject changed from test fails in pidgin_IRC to accept the 'ret' key from the protocol dialogue - send_key problem to [qam] test fails in pidgin_IRC to accept the 'ret' key from the protocol dialogue - send_key problem
Actions #12

Updated by pluskalm almost 7 years ago

  • Status changed from New to Closed

Probably caused by ninjakeys

Actions

Also available in: Atom PDF