One frame lag when clicking outside of the ImGui window/widgets?

[eliasdaler]

Looking at ImGui's source it seems like widgets' focus is checked when calling their creation functions, e.g. ImGui::InputText. This, unfortunately, seems to lead to the following problem.

I have a code like this:

if (!ImGui::GetIO().WantCaptureMouse) {
    if(inputManager.wasPressedThisFrame(sf::Mouse::Left)) { ... /* This code */ }
}

But when the focus is inside some text box and I click outside gui, the code with comment "This code" is not called. Text box releases focus (and WantCaptureMouse will be false) only after I call ImGui::InputText again. But in my code I first check input and then the update method is called in which ImGui widgets are created. So WantCaptureMouse becomes false after I call ImGui::InputText and the click gets missed.

Is there any way to fix this problem? Or should I call ImGui's widget creation functions before handling input to be able to handle mouse clicks correctly?

[eliasdaler]

Just to add a bit more to this.
Making widgets before processing input is a bad idea, because that will introduce input lag in one frame.

As for example when clicking outside of widget may happen: imagine having focus in some text box and then starting to drag selection in main editor window. Editor must register start of the click to position start of selection rectangle.

It seems like using IsHoveringAnyWindow instead of WantsCaptureMouse may help in this case, though I'm not sure that it's a perfect solution. (It's unlikely that this function will have such lag, even if it does, a lot of time will pass when user moves the mouse to the editor window, so IsHoveringAnyWindow will probably return false).

[ocornut]

For now I think the pragmatic direction is that you can use if (IsHoveredAnyWindow() || IsAnyItemActive() || IsPopupOpen(NULL, ImGuiPopupFlags_AnyPopupId)) as an alternative filter to io.WantCaptureMouse.

I realize this issue was opened a century ago but I believe it would apply to many people.

---

• User is lacking what we call bool mouse_avail in ImGui::UpdateHoveredWindowAndCaptureFlags(), the value of which can be helpful to differentiate quite a few situations, but IsAnyItemActive() is a decent proxy for it.
• From the point of view of the user it might be exposed as e.g "bool WantCaptureMouseButton" (don't mind the exact name), And then instead of using io.WantCaptureMouse you could use (IsHoveredAnyWindow() || io.WantCaptureMouseButton) as a filter.
• Adding the IsPopupOpen(0, ImGuiPopupFlags_AnyPopupId) part of the filter can be optional and is analogous so the open issue at Trigger widgets (per default) with the click that closes a popup #7681. As I think it would be tempted to add a new bool instead of suggesting people to manual testing, the result of this bool may evolve based on decision for Trigger widgets (per default) with the click that closes a popup #7681.
• Also see WantCaptureMouse and popups #4480 where we added io.WantCaptureMouseUnlessPopupClose, it's a similar problem.
• (One problem is that it becomes unclear what the meaning for a SetNextFrameWantCaptureMouse() call becomes. It's already technically the same problem that it overrides io.WantCaptureMouseUnlessPopupClose but since it's likely very rare that someone uses both I think no one complained)