action #17758
closedtest fails in libreoffice_double_click_file - probably sync/timing issue
100%
Description
Observation¶
openQA test in scenario sle-12-SP2-Desktop-DVD-Updates-x86_64-qam-regression-documentation@64bit fails in
libreoffice_double_click_file
The test opens nautilus, loops through a list of document files of various types and checks that they open without problems.
After checking the first one on the list (.doc), it wants to return back to nautilus (alt-tab) and proceed to the next document file
(.docx).
However, the alt key seems to get released in a wrong moment; the test does not return to nautilus and instead stays in the .doc file,
therefore cannot continue to the next file on the list.
Reproducible¶
Fails since (at least) Build 20170315-4
Expected result¶
Last good: 20170315-3 (or more recent)
Further details¶
Always latest result in this scenario: latest
Log: https://openqa.suse.de/tests/815852/file/autoinst-log.txt
Proposed solution¶
Adding wait_still_screen before releasing the alt key.
Updated by vsvecova over 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Updated by coolo over 6 years ago
the PR didn't really help.
But what is noticable:
19:43:47.8929 323 <<< testapi::wait_idle(timeout=5)
19:43:49.8947 324 wait_idle 0 d=117
19:43:50.8954 324 wait_idle 0 d=394
19:43:51.8961 324 wait_idle 0 d=509
19:43:52.8968 324 wait_idle 0 d=305
19:43:52.8975 323 >>> testapi::wait_idle: timed out after 5
I.e. the SUT has heavy load at that time.
Updated by vsvecova over 6 years ago
- % Done changed from 50 to 100
I checked the results of this test since the merge:
https://openqa.suse.de/tests/latest?flavor=Desktop-DVD-Updates&distri=sle&test=qam-regression-documentation&version=12-SP2&limit_previous=20&arch=x86_64&machine=64bit#previous
I notice two cases of a similar failure 5/6 days ago:
https://openqa.suse.de/tests/834430#step/libreoffice_double_click_file/88
https://openqa.suse.de/tests/831635#step/libreoffice_double_click_file/148
There have been a couple of other failures as well, but those don't seem to be related to this issue.
Apart from that, the test module has been mostly passing.
It is tricky to measure the impact of this change, and of course, is not a silver bullet, but I would say that this one can be safely closed.
Updated by vsvecova over 6 years ago
- Status changed from In Progress to Resolved