Most windows and apps with search fields follow this pattern, and Discover probably should too. Also, it's not as if keyboard focus is currently somewhere more interesting; in fact nothing at all seems to get focus right now, and hitting the tab key doesn't move it anywhere! Also, once upon a time this was done for Muon in bug 330049.
Patch: https://phabricator.kde.org/D24935
*** Bug 408106 has been marked as a duplicate of this bug. ***
Oops sorry, I didn't find your bug earlier.
Git commit 5d1b3718efb8eb88808c79165082521eff33a75d by Nate Graham. Committed on 25/10/2019 at 00:30. Pushed by ngraham into branch 'master'. Fix search field focus, both initial and on-demand Summary: Right now the search field doesn't get focus initially, or when the user types on a page. This is because the conditional loader that conditionally loads the GlobalDrawer's toolbar containing the search field isn't able to pass on focus or signals to its content properly. I tried various methods of fixing this by adding `focus: true` to all the focus stopes in the chain, but was unsuccessful. So this patch implements the conditional loading of the top content differently: instead the top content is always loaded, but conditionally discarded when in non-widescreen mode. This fixes the aforementioned issues. However it may not be the correct way to fix the problem; if not, assistance would be appreciated. FIXED-IN: 5.18.0 Test Plan: - Search field has focus when Discover is launched - Search field gains focus and accept text when typing anywhere - When the window is made mobiley, the sidebar's toolbar disappears - When a mobiley window is made desktoppy, the sidebar;s toolbar re-appears Reviewers: #discover_software_store, apol, davidedmundson Reviewed By: #discover_software_store, apol Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D24935 M +41 -40 discover/qml/DiscoverDrawer.qml https://commits.kde.org/discover/5d1b3718efb8eb88808c79165082521eff33a75d