Open m9710797 opened 5 months ago
It is probably another side effect of the ongoing #7325 debacle. I don’t think I will be able to check before monday, but if you can maybe see if it happens for you on 1.90.0.
I checked (git revision ce0d0ac8298). It also goes wrong there. Though the behavior is slightly different: in this version also the top level menu gets (wrongly) closed.
BTW I (only now) noticed that to trigger the bug (in both versions) it's required to move back to the same menu item in the previous sub-menu.
I couldn't repro this on Windows so I wonder if it is a Linux specific issue. Could you record a video of the issue, with the Debug Log open and [X] Focus [X] Viewports [X] Popups checked in there?
Here's a screen recording (I had to gzip it, otherwise github wouldn't accept the file type). I've also attached the log file in text format.
Let me know if you need any other information, or what I could do to help investigate.
In UpdateViewportsNewFrame()
, could you find that block:
if (apply_imgui_focus_on_focused_viewport)
{
focused_viewport->LastFocusedHadNavWindow |= (g.NavWindow != NULL) && (g.NavWindow->Viewport == focused_viewport); // Update so a window changing viewport won't lose focus.
ImGuiFocusRequestFlags focus_request_flags = ImGuiFocusRequestFlags_UnlessBelowModal | ImGuiFocusRequestFlags_RestoreFocusedChild;
if (focused_viewport->Window != NULL)
FocusWindow(focused_viewport->Window, focus_request_flags);
else if (focused_viewport->LastFocusedHadNavWindow)
FocusTopMostWindowUnderOne(NULL, NULL, focused_viewport, focus_request_flags); // Focus top most in viewport
else
FocusWindow(NULL, focus_request_flags); // No window had focus last time viewport was focused
}
and immediately before the opening brace add:
if (g.IO.KeyShift)
printf(""); // <--- ADD A BREAKPOINT HERE
if (apply_imgui_focus_on_focused_viewport)
{
This will allow you to easily break in debugger without altering the focus.
Then repeat the maneuver and start holding Shift before you know the issue will happen, and step in debugger.
Then in a debugger:
apply_imgui_focus_on_focused_viewport
focused_viewport->LastFocusedHadNavWindow
before and after the line attempting to complete it.Could you also confirm when you are holding mouse down and up? (some people browse menu by holding the mouse button down the whole way, some do multiple clicks).
After opening the first menu (with a mouse click) I'm not keeping any mouse buttons pressed. I'm only doing mouse movements.
apply_imgui_focus_on_focused_viewport == true
focused_viewport->LastFocusedHadNavWindow
is initially false
. It remains false
after the |=
operation (g.NavWindow != nullptr
, but g.NavWindow->Viewport != focused_viewport
).FocusWindow(nullptr, 3)
Does your Linux WM auto focus on hover ?
Yes, I have "focus follows mouse" enabled. If I set it to "Click to focus" then I cannot reproduce the issue anymore. But obviously that's not a solution ;-)
I'm very used to "focus follows mouse". I forgot this isn't the (default?) behavior in Windows, so it didn't occur to me to report this.
I never heard of this possible WM behavior before, I just yesterday guessed it may exists based on your report.
Unfortunately multi-viewports support seems to have many issues with Linux VM (and some with macOS).
It means the // Focused viewport has changed?
logic in that function is flawed in particularly the block coming from 3418d509 for #6462 (and see #6299 for previous commits related to same function).
Also linking to #2117 for general Linux support for multi-viewports (generally not well supporting).
The issue of clamping down the popup stack may be reproduced on most setup by removing the IsAnyMouseDown()
check:
const bool apply_imgui_focus_on_focused_viewport = /*!IsAnyMouseDown() &&*/ !prev_focused_has_been_destroyed;
And clicking back on that parent viewport. (And it also breaks #6462.)
Hi, thanks for looking into this!
In the past I did use "focus follows mouse" on Windows, but that was over 10 years ago. When I google for it today I found this. Maybe that makes it easier to investigate?
As a side note: I did notice that Dear ImGui windows behave different when they're fully inside the main application window compared to when they're outside. So far I couldn't put my finger on it (I also didn't actively investigate). But now, after your insight, I see that (at least one of) the differences is this "focus follows mouse" behavior.
Would it be an option to always create ImGui windows as native windows? That way they'll always behave like native windows. And maybe it'll simplify testing or expose problems sooner?? (No more separate code paths to handle both cases??). But then I must say I don't know too much about the Dear ImGui internals, and you may have good reasons for the current design. (I can imagine native windows require more resources, so you only want to create them when really needed??)
They are native windows. I'm not sure what you are saying. If you mean you want them to use WM decoration, you can set io.ConfigViewportsNoDecoration = false
in code or Demo->Configuration but I don't think that will solve any problem.
Sorry I wasn't clear. I meant when a Dear ImGui window is fully contained inside the main application window. So when no extra viewport is needed.
At least I had the impression that viewports map to native windows. Maybe I'm wrong.
The NoAutoMerge flag does that but it indeed exposes too many problems.
The current situation is that I don’t have resources to rewrite/redesign this system to accommodate for every eccentric WM features (worst offender being Wayland’s policies), so unfortunately it is unlikely to be fixed in the mid term. But here’s hoping that a redesign of viewports will improve things for Linux users. It’s just currently way off the priority list and too much of a time sink.
I understand. No problem. Thanks a lot anyway.
The issue was originally reported in our project openMSX (hi @m9710797) running on Windows.
I couldn't repro this on Windows so I wonder if it is a Linux specific issue.
Assuming this is the same as I described here, then this also happens on macOS. It seems to specifically happen when a menu item has a tooltip and the menu or the tooltip go outside the window boundaries. (My mouse cursor stays within the window region at all times though.)
I shall investigate if it happens with stock macOS VM, but barring that we could have some settings to disable focus-imgui-window-on-platform-focus as a workaround for some systems.
Version/Branch of Dear ImGui:
Version 1.90.5, Branch: docking
Back-ends:
imgui_impl_sdl2.cpp + imgui_impl_opengl3.cpp
Compiler, OS:
Linux + GCC 13
Full config/build information:
Details:
I tried to search for existing tickets about this issue but I couldn't immediately find anything, I'm sorry if I overlooked something.
I can reproduce the problem with the (unmodified) demo application
imgui/examples/example_sdl2_opengl3/example_sdl2_opengl3
:In my application I had a variation on the above:
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code: