UI TestEngine: precise modal-blocked detection (fix #5961 regression)

[Grantim]

Summary

Replaces the overbroad rootLevelBlocked() heuristic in UI::TestEngine::Control with a per-widget check done at registration time. Fixes the test_ui regression ubuntu22-arm64 build-test on MeshInspectorCode#7242.

The regression

PR #5961 added status reporting and typed errors from pressButton/writeValue for disabled-or-blocked widgets. The "blocked by modal" branch used ImGui::IsPopupOpen("", AnyPopupId | AnyPopupLevel) — true whenever any popup is open anywhere. It flagged every root-level entry, including buttons that actually lived inside the modal. Test scenarios pressing modal-own buttons like Don't Save on the New scene confirmation dialog hit a typed error instead of being simulated, Python propagated, MeshInspector terminated with exit 6:

[error] RuntimeError: pressButton Don't Save: disabled: blocked by modal 'New scene##new scene'
terminate called without an active exception

test_all_scens.py::test_all_scenarios[main_set/features/select/qase_regression] all fail as a result.

Why the heuristic was wrong

The UI::TestEngine tree (pushTree/popTree) is independent of ImGui's window/popup structure. MeshInspector's New scene confirmation dialog registers its Don't Save button via createButton(...) without a surrounding pushTree, so the button sits at the TestEngine root. A global "any popup open" test can't distinguish "at root behind the modal" from "at root inside the modal."

The fix

Do the check at widget registration time (where ImGui::GetCurrentWindow() is valid) and fold the result into the existing disabledReason string on the internal entry. A widget whose current window is not in the topmost blocking modal's ancestor chain gets disabledReason = "blocked by modal '<name>'" for that frame; widgets inside the modal (or with no modal open) get an empty reason. listEntries, pressButton, writeValue, and composeStatus already consume disabledReason — no per-caller changes needed.

Concretely:

• MRUITestEngine.cpp :: effectiveDisabledReason — return type bumped from std::string_view to std::string; after the caller-reason and BeginDisabled auto-detect branches, falls back to checking ImGui::GetTopMostPopupModal() and walking the current window's ParentWindow chain. If the widget is outside the modal, format "blocked by modal '<name>'".
• MRUITestEngineControl.cpp — rootLevelBlocked() and topBlockingModalName() deleted; composeStatus collapses to a single std::string_view disabledReason input; listEntries/pressButton/writeValue drop the blockingModal branch and the path.size() == 1 special case (the per-entry reason now carries all needed info).
• No header changes, no API surface change. ButtonEntry::disabledReason and ValueEntry::disabledReason already store std::string. MCP status and Python UiEntry.status produce the same three shapes as before: "available" | "disabled: <reason>" | "disabled: blocked by modal '<name>'".

Secondary improvement: switches from IsPopupOpen(AnyPopupId|AnyPopupLevel) to GetTopMostPopupModal(), so non-modal popups (tooltips, BeginPopup without _Modal) no longer count as blockers.

Test plan

Verified live via MCP against Debug build:

• Root with no modal — every entry "available".
• RibbonSceneButtons/* with empty scene — "disabled: <ribbon requirement>" (unchanged — the requirement-based path isn't touched).
• Open Toolbar Customize popup → root entries BEHIND the modal (##Cube, Create Object, Watch Video, Information, Show on Startup) report "disabled: blocked by modal 'Toolbar Customize'".
• Same scenario → entries INSIDE the modal (Toolbar Customize/##About, Toolbar Customize/Reset to default, etc.) report "available".
• pressButton(["Toolbar Customize", "Reset to default"]) (inside modal) returns {} — no typed error.
• pressButton(["Toolbar", "##ToolbarCustomizeBtn"]) (behind modal) returns "pressButton .../...: disabled: blocked by modal 'Toolbar Customize'" — correct typed error on a widget NOT in the modal, at any path depth.

The CI-regression case (Don't Save inside New scene##new scene) is the symmetric "inside-modal at root" path: the widget's current window == the top modal → disabledReason stays empty → status: "available" → pressButton succeeds.

🤖 Generated with Claude Code

[oitel]

Why is this not in a separate function like imGuiContextSaysDisabled()?

[Grantim]

Done in 49e16c9. imGuiBlockingModalName() is now a peer of imGuiContextSaysDisabled(); effectiveDisabledReason becomes a three-line if-chain. Live-verified the status output is unchanged.