Bug 501822

Summary:	Hitting tab key when search or replace is open inputs into document
Product:	[Applications] ghostwriter	Reporter:	Riccardo Robecchi <sephiroth_pk>
Component:	general	Assignee:	megan.conkle
Status:	CONFIRMED ---
Severity:	normal	CC:	miniopl
Priority:	NOR
Version First Reported In:	24.12.3
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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.