[Bug] Certain tooltips steal focus from main window

[stkptr]

Operating System

Linux

What's the issue you encountered?

When hovering over certain types of items which present tooltips, the main window's focus is given to the tooltip. This prevents typing if there is a tooltip currently on screen, and can interfere with basic window operations.

This occurs with errors in the pattern editor, as well as image tooltips in the pattern data view.

How can the issue be reproduced?

Create an erroneous pattern in the editor, then hover over any errors.

ImHex Version

1.36.2

ImHex Build Type

• Nightly or built from sources

Installation type

AppImage

Additional context?

Using Debian 12 with Xfce.

[paxcut]

Thanks for the report. I am not able to reproduce this problem. The description for reproduction is too vague so I tried a few things:

1. created a pattern with an error. Evaluated the pattern so that error marker appears on text editor. Started to edit on the hex editor and hovered over the patterns editor error marker to see the tooltip. Hex editor focus and editing ability remained unchanged.

2. created a pattern with an error. Evaluated the pattern so that error marker appears on text editor. Put focus back on text editor (Note: If the issue is that the pattern editor losses focus when being evaluated this has been addressed on PR fix: auto evaluate doesn't work with undo. #2106 and it is waiting to be merged). Hovering over the marker so that tooltip appears does not make the pattern editor lose the focus it had.

3. Opened a bmp file and imported the bmp pattern. Evaluated the pattern to create highlights in the hex editor. Started to edit the hex editor view. Hovering over the highlights which present tooltips does not remove the focus for editing. I also tried hovering over things around the entire ImHex display and did not lose the editing ability or its focus. When hovering over the icon to see the image no tooltip was produced. To show the image it is required to click on the icon which naturally removes the focus from whatever had it before.

4. created a pattern with no errors. Evaluated the pattern to create highlights in the hex editor. Started to edit on the pattern editor. Hovering over the hex editor highlights that produced tooltips did not remove editing ability or focus to the pattern editor window. Hovering over any other part of ImHex did not remove focus from the pattern editor.

If the issue here is not covered by any of the cases above, please post a set of step by step instructions for reproduction with as much detail as possible. Even if it seems that it is not necessary to add some detail it may help to mention it so that we don't have to try all the alternative steps that are possible and may be related to the issue.

[stkptr]

I have not tried to reproduce on other operating systems or window managers, only with Xfce on Debian. That is likely why you are having issues reproducing the issue.

On my system it is very easy to reliably reproduce by hovering over an underlined error in the pattern editor. The main window loses focus (most notably indicated by the window decoration styling changing to the unfocused style) and cannot be typed in until the tooltip is moved away from.

I will try to reproduce this issue on a couple other window managers, and on a clean slate Xfce system. From experience, this issue is likely window manager related. This does not mean that there isn't a bug in ImHex, but it likely only appears on certain WMs. My guess is that Windows does not have this issue.

[stkptr]

The issue seems to only occur when the tooltip is able to escape the parent window. This happens most often for large error messages like for the pattern struct E {}; E a[0x100000] @ 0; then hovering over the 0. It also only occurs if "Enable Multi Window support" is enabled in the options. The focus of the main window is taken by an "Untitled Window" which contains the tooltip, which is only created if the tooltip is supposed to escape the main window's bounds.

Reproduction steps:

1. Use Xfce (this may not be applicable, I need to test on more than just Xfce)
2. Enable Multi Window support in settings
3. Create a tooltip which would escape the window (make the window small, use the code snippet above in the pattern view)
4. Hover over the tooltip

The tabs of the pattern editor or other subwindow should change color, typing should result in no text being input into the previously focused subwindow, and the window manager's decorations (if applicable) will reflect that the window is now in the background.

[WerWolv]

Thank you. The solution for this is really to just disable the multi window support again. It's disabled by default on Linux because various desktop environments don't play nice with it there. Gnome and KDE work decently with it but there's tons others sadly that don't.

Ultimately it's an ImGui issue and should be reported there, I don't believe there's much I can do over here, sorry.

[stkptr]

For posterity, I tested the following platforms:

• Windows (10): no issues seem to be present
• Debian Xfce (X): tooltip appears in normal place, but steals focus
• Debian Gnome: tooltip appears at top left of the screen, and steals focus
• Debian KDE (Wayland): tooltip appears in the middle of the screen with window decorations, steals focus

[WerWolv]

Huh you're right about gnome for the very least, for me it also appears in the middle of the screen now. This definitely used to work better in the past. Not perfectly, but better for sure

[WerWolv]

Nevermind, the Wayland issues have always been there. The reason is that Wayland, by design, does not allow applications to move their own windows around programmatically. So ImGui has basically no way of handling these popups or even detached windows correctly. The focus stealing might be some Window flag that needs to be set (at least Windows has something like this) but I'm not entirely sure about Linux

[paxcut]

I don't think focus stealing is an issue if popups are contained in main docking window. It is possible to move an image visualization outside of the window and it will also remove focus from main window. you need to click on the main docking window to close the visualizer anyway.

[WerWolv]

It's fine for detached windows yeah. But it makes things unusable with tooltips

[WerWolv]

fwiw ImGui tries to prevent this issue from happening but, from the looks of it, those window attributes seem to be entirely ignored by the WM. Prebuilt versions of ImHex use GLFW 3.3 or 3.4 now so GLFW_FOCUS_ON_SHOW should be supported

    // GLFW 3.2 unfortunately always set focus on glfwCreateWindow() if GLFW_VISIBLE is set, regardless of GLFW_FOCUSED
    // With GLFW 3.3, the hint GLFW_FOCUS_ON_SHOW fixes this problem
    glfwWindowHint(GLFW_VISIBLE, false);
    glfwWindowHint(GLFW_FOCUSED, false);
#if GLFW_HAS_FOCUS_ON_SHOW
    glfwWindowHint(GLFW_FOCUS_ON_SHOW, false);
 #endif