Keyboard navigation inconsistency depending on types of nodes in multiple columns

[katemonster33]

Version/Branch of Dear ImGui:

Version: v1.89.5
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_dx12.cpp + imgui_impl_win32.cpp
Compiler: VS2022
Operating System: Windows 10

My Issue/Question:
I am attempting to create a window that has a table with 2 columns, 1 row. Each column has multiple CollapsingHeader, TreeNode and Selectable within it. If all the objects are of the same type, navigation works as expected: down arrow moves a node down, right moves a column to the right, etc etc. But as soon as you begin mixing different node types, navigation breaks completely. Sometimes pressing down moves you a column to the right, sometimes pressing up moves you to the left. It's hard to predict. Unfortunately many of my users do not have mouses, so consistent keyboard navigation is a must.

Screenshots/Video

XXX (you can drag files here)

Standalone, minimal, complete and verifiable example:
ImGui::Begin("table test"); if( ImGui::BeginTable( "table1", 2 ) ) { ImGui::TableNextColumn(); ImGui::CollapsingHeader( "1" ); ImGui::CollapsingHeader( "2" ); ImGui::CollapsingHeader( "3" ); ImGui::CollapsingHeader( "4" ); ImGui::CollapsingHeader( "5" ); ImGui::TableNextColumn(); ImGui::CollapsingHeader( "6" ); ImGui::CollapsingHeader( "7" ); ImGui::CollapsingHeader( "8" ); ImGui::EndTable(); }
^works
ImGui::Begin( "table test 2" ); if( ImGui::BeginTable( "table1", 2 ) ) { ImGui::TableNextColumn(); ImGui::CollapsingHeader( "1" ); ImGui::Selectable( "s1" ); ImGui::CollapsingHeader( "2" ); ImGui::CollapsingHeader( "3" ); ImGui::CollapsingHeader( "4" ); ImGui::CollapsingHeader( "5" ); ImGui::TableNextColumn(); ImGui::CollapsingHeader( "6" ); ImGui::CollapsingHeader( "7" ); ImGui::Selectable( "s2" ); ImGui::CollapsingHeader( "8" ); ImGui::Selectable( "s3" ); ImGui::EndTable(); }
^broken

[ocornut]

This is an issue with the directional navigation scoring system, similar to #6003 and #1688 (also related to #2694).
I am going to see if I can have a pass at fixing this.

The issue is made apparent with item of varying heights and spacing.

(It might also be exacerbated by the fact that both CollapsingHeader() and Selectable() have extruded padding, but that part alone we can easily fix by passing the non-padded nav-rect to ItemAdd(). But this is only worth fixing when the main issue is fixed).

[katemonster33]

@ocornut do you know of any work-around besides forcing all items to be the same type?

[ocornut]

The type of item doesn't matter, the issue here is due to their relative height.
I suppose if you are extra spacing between both column it might alleviate some of it.
Otherwise this is a bug I would like to look at fixing soon.

[katemonster33]

FYI @ocornut I applied the fix mentioned in #6003 and it made things much better. Pressing down key on CollapsingHeader still likes to send you a column to the left but I am working around it by using SeparatorText instead for now.

[ocornut]

If you don't mind I would like to keep it open as it has been among my reference/test cases for a rework of some nav scoring logic.

[averne]

I'm happy to hear that the nav scoring is getting some attention. If you want me to try a patch, or send some code to reproduce the layout in #6003, I'd be glad to do so.

[katemonster33]

The reason I closed it is because I tried with some test code I had locally, and the keyboard navigation felt more consistent. If you want to keep it open that's fine

[Reedbeta]

I have also recently run into this issue. I created a table containing one column of TreeNodes and another column of Buttons, and observed that pressing the up arrow on a TreeNode would send me to the Button on the previous row.

Given the hint here about varying item heights (thanks!), I was able to work around it by using the equivalent of SmallButton. That both fixed the keyboard navigation, and fixed my line spacing (as the buttons originally forced the line spacing wider than it would be for TreeNodes alone), so it's a good solution for me.

In case it's of interest, here's a bit of test code that repros the problem:

if (ImGui::BeginTable("Test Key Nav", 2))
{
    ImGui::TableNextRow();
    ImGui::TableNextColumn();
    if (ImGui::TreeNode("Item1"))
        ImGui::TreePop();
    ImGui::TableNextColumn();
    ImGui::Button("Button1");

    ImGui::TableNextRow();
    ImGui::TableNextColumn();
    if (ImGui::TreeNode("Item2"))
        ImGui::TreePop();
    ImGui::TableNextColumn();
    ImGui::Button("Button2");

    ImGui::EndTable();
}

Switching the Buttons for SmallButtons works around the issue.