Created attachment 1890103 [details] Video showing the problem. Description of problem: In openQA, we test several tests that utilize the following process: 1. Open the launcher. 2. Type the application name. 3. Press Enter to open it. However, this process started to fail recently, because KDE places the focus incorrectly, so hitting the enter does not make sure that the correct application is started. You can see the situation in the attached video and on the attached screenshot. When the launcher is started, and the "konsole" string is typed, it offers two records (Konsole and Default Application), but the focus is placed on the Default application (and not Konsole) so when enter is hit, the Konsole does not start as expected. Instead, Default applications is started. Version-Release number of selected component (if applicable): KDE on 20220614 compose. How reproducible: Always reproduced in a VM run by the openQA test engine. Steps to Reproduce: See the attached video. Actual results: Incorrect focus placed when application name is typed. Expected results: Focus should be placed correctly so the expected application will start when called for.
Created attachment 1890105 [details] The screenshot depicting the situation.
I tried to reproduce the problem manually in another VM and the occurrence is much less frequent. It seems that the speed of hitting the Enter key after the application name has been typed plays an important role as if the GUI needed some time to deal with placing the focus. However, the issue is still reproducible with certain applications, such as Dolphin, where the focus sometimes stays on Locations, so Settings will be opened instead of Dolphin.
Having inspected a little bit longer and I found the culprit. It seems to be the mouse cursor. If the cursor happens to be left in the position where the launcher will open, it will always select the one item which is found below the mouse cursor because it takes precedence over the automated selection based on the name of the application. I believe that this is a problem, because nobody expects that the mouse (not being used at the time) will affect the launcher when they are using the keyboard to navigate in it.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
I can't replicate this on F37? Is it still erroring in OpenQA?
I am no longer seeing it.