Fix issue #9001 Make ConfigInputTextEnterKeepActive compatible with IsItemDeactivatedAfterEdit

[XttZjj]

Fixes #9001.

Summary

When io.ConfigInputTextEnterKeepActive is enabled, pressing Enter on a single-line InputText keeps the widget active and selects the contents.
However, in this mode the item is never considered "deactivated", so IsItemDeactivatedAfterEdit() never fires and existing undo/finalization logic breaks.

Issue

• Without ConfigInputTextEnterKeepActive:
  • Pressing Enter deactivates the item, and IsItemDeactivatedAfterEdit() becomes true for one frame.
• With ConfigInputTextEnterKeepActive:
  • Pressing Enter keeps the item active, and IsItemDeactivatedAfterEdit() is never triggered.
• This is the situation described in IsItemDeactivatedAfterEdit doesn't play nicely with ConfigInputTextEnterKeepActive #9001, where code that relies on IsItemDeactivatedAfterEdit() to finalize edits stops working.

Fix

• On Enter, when ConfigInputTextEnterKeepActive is set, I:
  • Let the widget go through the normal "deactivated after edit" path so that IsItemDeactivatedAfterEdit() is signaled as usual.
  • Immediately reactivate the same InputText for the next frame and select its contents.
• This preserves the existing idiomatic use of IsItemDeactivatedAfterEdit() while keeping the behavior promised by ConfigInputTextEnterKeepActive.

Testing

• Reproduced the behavior described in IsItemDeactivatedAfterEdit doesn't play nicely with ConfigInputTextEnterKeepActive #9001:
  • IsItemDeactivatedAfterEdit() never triggered with ConfigInputTextEnterKeepActive enabled.
• Verified after the patch:
  • IsItemDeactivatedAfterEdit() is true for one frame when pressing Enter, even with the config flag set.
  • Focus remains on the input and text is selected as before.
• Also checked:
  • Pressing Enter without ConfigInputTextEnterKeepActive (unchanged behavior).
  • Clicking outside the widget to deactivate.
  • No regressions observed in basic InputText examples.

[ocornut]

Rebased and removed noise from commits.

[ocornut]

I have merged your fix 03a9946, then reworked it as 5aa7d61 which includes fixing a race condition if e.g. the InputText() gets hidden (stops being submitted) after returning true the deactivation request would linger and trigger later.
I have reworked three of the tests to exercise this newly supported path: ocornut/imgui_test_engine@bbe1f01

Thank you!

[ocornut]

For reference a basic test bed for this would be:

io.ConfigInputTextEnterKeepActive = true;

static char buf[256] = "hello";
bool ret = ImGui::InputText("Blah", buf, 256, 0);
ImGui::BulletText(
    "Return value = %d\n"
    "IsItemFocused() = %d\n"
    "IsItemHovered() = %d\n"
    "IsItemActive() = %d\n"
    "IsItemEdited() = %d\n"
    "IsItemActivated() = %d\n"
    "IsItemDeactivated() = %d\n"
    "IsItemDeactivatedAfterEdit() = %d\n"
    "IsItemVisible() = %d\n"
    "IsItemClicked() = %d\n"
    "IsItemToggledOpen() = %d\n",
    ret,
    ImGui::IsItemFocused(),
    ImGui::IsItemHovered(),
    ImGui::IsItemActive(),
    ImGui::IsItemEdited(),
    ImGui::IsItemActivated(),
    ImGui::IsItemDeactivated(),
    ImGui::IsItemDeactivatedAfterEdit(),
    ImGui::IsItemVisible(),
    ImGui::IsItemClicked(),
    ImGui::IsItemToggledOpen()
);

I also confirmed in slow-motion that this doesn't happen to lead to e.g. one frame flickers.