r11770 - network window scroll bar bug

[Andarix]

This bug has been around for quite some time.

The scroll bar for the server list is in the list and not below the list.

[prissi]

That is very hard to rectify, as the size is only known until the first redraw when it is too late to resize ...

[victor_18993]

I think the size can be known a little earlier than it first seems, at least in this particular case.

What seems to be happening

gui_scrolled_list_t always enables the vertical scrollbar. Because of the !b_show_scroll_y check added in r11418, get_max_size() never leaves space for the horizontal scrollbar when the vertical one is enabled.

That means the list can end up with a maximum height equal to the exact height of its rows. gui_aligned_container_t::set_size() then limits the pane to that height, and recalc_sliders() places the horizontal scrollbar at:

Code Select Expand

size.h - D_SCROLLBAR_HEIGHT
So the scrollbar is drawn over the list contents.

With a longer list this is easy to miss, because only one row is covered and it can still be reached by scrolling. With a list containing only one entry, the scrollbar covers almost everything, which seems to match Andarix's screenshot.

Possible change

It is true that scroll_x.is_visible() is only fully known after the first redraw. However, I think we can already predict whether the horizontal scrollbar will be needed from the content width, since the layout asks for that information anyway.

I tried adding:

Code Select Expand

bool gui_scrollpane_t::needs_scroll_x() const
{
 return b_show_scroll_x &&
 (scroll_x.is_visible() || comp->get_min_size().w > max_width);
}
and using it in get_max_size() instead of:

Code Select Expand

scroll_x.is_visible() && !b_show_scroll_y
As far as I can see, this should not reserve too little space. If the content fits inside the available width, the horizontal scrollbar is not needed.

The worst case I can see is reserving one extra scrollbar height at the bottom of a short list when the window is wider than the content. I left get_min_size() unchanged, because the vertical scrollbar's own minimum already seems to dominate there.

What I tested

I made clean builds before and after the change using the same configuration, with no new warnings. git apply --check also succeeds against the base commit.

I then opened the network dialog in both the baseline and patched builds using the same automated sequence and compared the resulting screenshots pixel by pixel. They were identical, so I could not find any visible regression in the cases that are currently available.

One limitation

Unfortunately, I could not reproduce the original screenshot with the current server list.

The issue seems to require a very short list — probably around three entries or fewer — with at least one entry wider than the pane. At the moment, the announce list gives this client 0, 5 or 10 entries, and with five entries the longest server name still fits, so the horizontal scrollbar does not appear.

Back in October 2025, only one server matched Andarix's revision, and that entry also included a second IPv6 address. That would have created one very wide row on its own, which seems to be exactly the case where this becomes visible.

So this explanation is based on following the size calculation rather than reproducing the original result directly.

Andarix, if you are still able to trigger it, a before-and-after screenshot with the patch would be very helpful to confirm that I have understood the issue correctly.