Gamepad navigation wrap-around is confusing

[SupSuper]

Currently when navigating widgets via gamepad, when the selection reaches the bottom, ImGui will wrap around to the first widget currently visible, instead of the first widget in the window. This seems to be by design:

imgui/imgui.cpp

Lines 9326 to 9341 in 9c77734

	// When using gamepad, we project the reference nav bounding box into window visible area.
	// This is to allow resuming navigation inside the visible area after doing a large amount of scrolling, since with gamepad every movements are relative
	// (can't focus a visible object like we can with the mouse).
	if (g.NavMoveRequest && g.NavInputSource == ImGuiInputSource_Gamepad && g.NavLayer == ImGuiNavLayer_Main)
	{
	ImGuiWindow* window = g.NavWindow;
	ImRect window_rect_rel(window->InnerRect.Min - window->Pos - ImVec2(1, 1), window->InnerRect.Max - window->Pos + ImVec2(1, 1));
	if (!window_rect_rel.Contains(window->NavRectRel[g.NavLayer]))
	{
	IMGUI_DEBUG_LOG_NAV("[nav] NavMoveRequest: clamp NavRectRel\n");
	float pad = window->CalcFontSize() * 0.5f;
	window_rect_rel.Expand(ImVec2(-ImMin(window_rect_rel.GetWidth(), pad), -ImMin(window_rect_rel.GetHeight(), pad))); // Terrible approximation for the intent of starting navigation from first fully visible item
	window->NavRectRel[g.NavLayer].ClipWithFull(window_rect_rel);
	g.NavId = g.NavFocusScopeId = 0;
	}
	}

But our users found this behavior really confusing, specially in list/combo boxes. Any chance it could be configurable?

[ocornut]

Hello,

This is discussed specifically in this comment:
#4079 (comment)

I just committed some partial refactor (393941c) which is getting us closer to being able to move the focusable registration before clipping, as it is now performed in ItemAdd() literally clipping and focus registration are now next to each others...

...However they can't be trivially swapped yet because it would require us to scroll to keep target item visible in order to be useful (if you Tab out of sight it would be wrong). So while doing that simple swap would fix #4079 and #343 it would currently come with a bigger regression in term of user experience.

Given the current code we have access to the positional data too late in the frame since scroll needs to be locked in Begin(). So with current code structure the dumb solution would requires us to first focus/tab the next widget on frame N and then scroll on frame N+1, which is the kind of horrible scrolling experience you'd expect from an Android TV.

TL;DR; work has been done to move toward supporting this but need more work to allow scrolling to follow and then this'll be possible.

[ocornut]

I apologize, I misunderstood your post for a similar but different issue.
The thing solved by #4079 was due to focus-tabbing not working on non-visible items. This is actually different.

This seems to be by design:
But our users found this behavior really confusing, specially in list/combo boxes. Any chance it could be configurable?

That code was meant to solve a different problem but not this one. In the case of wrapping around, this was a bug.
Now fixed by 26e59c8 !

Thank you for your report!