Multi-viewport: window constrained to main viewport moves if it goes outside of viewport

[EmilDohne]

Version/Branch of Dear ImGui:

Version 1.90.5, Branch: docking

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp

Compiler, OS:

Windows 10 + MSVC 2022

Full config/build information:

No response

Details:

My Issue/Question:

I noticed that my window, which is constrained to the main viewport, created in a Multi-viewport environment "moves" (stays in place) when I move the main viewport window. It only does this if the window is partially outside of the main viewport. I did this constraining using a hack I found on here by setting the next window viewport (see the code example).

I'm not sure if this is the best way to go about it and I'm also happy to accept a solution that constrains the window to the main viewport and doesnt let it go outside in the first place as that would actually be the preferred behaviour.

Thanks in advance! Let me know if anything is unclear :)

Screenshots/Video:

Minimal, Complete and Verifiable Example code:

ImGui::SetNextWindowViewport(ImGui::GetMainViewport()->ID); // Disable this widget from popping out
ImGuiWindowFlags window_flags = 
    ImGuiWindowFlags_NoCollapse 
    | ImGuiWindowFlags_NoBringToFrontOnFocus
    | ImGuiWindowFlags_NoDocking;
ImGui::Begin((std::string(ICON_FA_GRIP_LINES) + " Layer Stack").c_str(), nullptr, window_flags);
// Left out for brevity
ImGui::End();

[ocornut]

This is caused by the logic pushed in 967073b, specifically this:

ImRect test_still_fit_rect(old_pos, old_pos + viewport->Size);
[...]
if (window->Viewport == viewport && test_still_fit_rect.Contains(window->Rect())
   TranslateWindow(window, delta_pos);

The problem is this logic is meaningful when un-maximimizing a window.

I pushed what I think is a good workaround 8040c02 that preserves the property desired by the previous change.

Also added an automated regression test for it:
ocornut/imgui_test_engine@ac827fa

Thanks for reporting!

[EmilDohne]

Thanks a lot for the extremely quick fix! I can confirm this is now working on my end (after porting the changes to my custom fork)