dragonmacher
commented
3 years ago Obviously, without us being able to reproduce the issue, this will be tough to diagnose.
This sounds different to me than the ticket you mentioned above. That ticket is dealing with a lockup of the entire UI. If I read your info correctly, Ghidra still works for you, other than the keyboard input? The UI still paints and your mouse actions still work, I'm assuming.
We have seen in the past on different versions of Linux the issue of keyboard input not working. That has typically been an issue of a focus handshake between the main UI and temporary dialogs (potentially the data type chooser in you case). In the past, you were able to sometimes fix the issue by using another text field inside of a modal dialog after the tool gets into this state. So, to try this, the next time you find the tool in this state, try using a text field inside of a modal dialog. For example, in the bad state, go to the menu bar with the mouse and press Navigation -> Go To... and see if you can type in the text field in that dialog.
As you mentioned, this could be related to the text field that appears inside of the structure editor. Along the same lines as above, you can try to edit a structure data type from within the structure editor when the tool gets into this state. The hope here would be that by using again the data type chooser from the structure editor may reset the focus owner state of the system.
My guess with all this is that the focus owner gets lost during Alt-Tab usage while the focus is in a transient Ghidra widget, such as a temporary editor (like the Data Type Editor in the Structure Editor) or in a text field within a modal dialog.
foreverWIP
gipi
madebr
mumbel
SchrodingersMind
tonybounty
PJ-Zetier
ryanmkurtz
Describe the bug When entering text into a text field in the CodeBrowser, occasionally most of the the GUI (including the CodeBrowser window and the main project window) will no longer react to any keystrokes, whether it's a text field that's selected for input, or general shortcuts like Ctrl+S for saving. The only parts that still respond to keystrokes are the Console window and all "rich text" widgets (like the bottom of the Script Manager that displays information about a selected script, as well as the right-hand side of the Help window that displays the page contents). The only way to "fix" the issue is restarting Ghidra. While I can't pinpoint a specific case of the issue occurring, it tends to happen more often when either switching windows (Alt+Tab) immediately before/after/while entering text, or while entering text in the data type chooser (most often in the structure editor, but has happened in the listing display as well).
To Reproduce I can't yet find a specific way to trigger the bug every time, but a general example of how it occurs goes as follows:
Expected behavior The GUI still reacts to keyboard input, for text entry and shortcuts, even after repeatedly gaining and losing focus.
Attachments Thread dump taken from jstack
Environment:
Additional context Mouse input continues to be handled after the bug occurs. The issue also occurs when running support/ghidraDebug, and nothing about the issue is logged there. Configuring focus stealing prevention in Plasma settings does not prevent the issue. The closest related issue I could find is #1516, and while the source of the bug may not be the same, the way the GUI stops responding here makes me think it could be a threading issue, or keyboard focus from one GUI window not properly switched upon closing (the GUI for the data type completion occasionally shows up as generic X11 windows in my taskbar, so I feel like that might be related as well). I will update this report if I find a more consistent way of triggering the bug.