Bug 501822 - Hitting tab key when search or replace is open inputs into document
Summary: Hitting tab key when search or replace is open inputs into document
Status: CONFIRMED
Alias: None
Product: ghostwriter
Classification: Applications
Component: general (other bugs)
Version First Reported In: 24.12.3
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: megan.conkle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-21 09:06 UTC by Riccardo Robecchi
Modified: 2025-07-13 18:55 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Riccardo Robecchi 2025-03-21 09:06:21 UTC
SUMMARY
When you open the replace function, it is intuitive to hit "tab" to go from the "search" field to the "replace" field. However, this does not work, and pressing the tab key actually inputs the key in the document. The same happens with the search function.

STEPS TO REPRODUCE
1. Open the search or the replace function
2. Hit the "tab" key

OBSERVED RESULT
A tab spacing is input in the document.

EXPECTED RESULT
The focus goes to the next field in Ghostwriter's UI.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE Neon
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2

ADDITIONAL INFORMATION
Comment 1 Mirek Długosz 2025-07-13 18:55:55 UTC
I can confirm this happens when using ghostwriter build from source using kde-builder, git hash 4bdd9c4cd30c68c79f8d2636dfa9e8d10de8a27c .

The problem is that menu action "IndentText" is assigned accelerator "Tab" in src/appactions.cpp:118. That action takes precedence over everything else. MainWindow overrides keyPressEvent and detects if findReplace widget is visible, to redirect event there. FindReplace has code to handle Tab, to move between "Find" and "Replace" when they are visible. But neither FindReplace nor MainWindow code is ever run, because key press is handled by action first.