#2946 Scrollbar in Route Manager broken in 2024.1

[ranguli]

For context, when you create or load a flight plan that has enough waypoints to require scrolling, the scroll bar (which would otherwise be hidden) becomes visible, that's the intended behavior. The bug is that instead of the scrollbar being appropriately sized and contained within the PUI window, it stretches the entire height of the FlightGear window, and the scrollbar no longer works.

This ends up significantly impacting usage of the Route Manager in 2024.1, as you can't scroll to see all of your added waypoints.

Reproduction Steps:

1. Start FlightGear 2024.1, it should not matter which aircraft you choose.
2. Open Autopilot > Route Manager
3. Load the attached .gpx route file
4. Observe that the scrollbar is misbehaving
5. Delete waypoints until they can all fit on the screen.
6. Observe that the scrollbar hides again (as normal).

[ranguli]

This has been reproduced by myself and one other user. Both on Linux, but with different integrated graphics cards (one was Intel, the other AMD).

As well, here is the .gpx route for ease of reproduction. You can also reproduce by simply adding several waypoints too.

[ranguli]

As well, it's worth noting that the white rectangle in the top-right screen is unrelated to this bug report. The user that passed along the screenshot happened to be lucky enough to capture two bugs at once. It has already been reported as #2943.

[James Turner]

that's really weird, I was testing the dialog a lot recently and didn't see this. But I'll investiagte.

[James Turner]

tried to reproduce this locally and no luck.

[Henning]

I can reproduce it with 2024.1.1. Add enough waypoints and the scrollbar appears full window height. Resize the route manager window makes it dis/appear depending on size.
Searching for another scrollbar I found the "automatic download(terrasync)" dialog to have its scrollbar working correctly but that uses a different widget.
I guess we need to check fg/src/GUI/WaypointList.cxx which was not changed recently AFAI see

[James Turner]

@jsb1685 on Linux, I guess? or Windows?

[Henning]

Linux

[James Turner]

Hmm I wonder, is it something in the pre-build PLIB.

Can someone on Linux try with self-compiled PLIB? The macOS build eg uses the code from plib-trunk here:
https://gitlab.com/flightgear/macos-3rd-party/-/tree/main/plib?ref_type=heads

[Gijs]

FYI, I cannot reproduce this on Windows 10.

[James Turner]

I can reproduce this on Linux using the distro PLIB: going to see if the internal numbers are off, or what else might be occuring.

[James Turner]

Okay, with self-compiled PLIB from plib-trunk (actually I used the copy on macos-2rdparty, but it should be identical as far as Linux is concerned,), the bug is fixed.

Can someone on Linux please confirm this result? You will need to uninstall any distro PLIB completely, and adjust your FlightGear Cmake invocation to ensure the PLIB install prefix dir is added to CMAKE_PREFIX_PATH of course.

[James Turner]

Fixed in FG commit 8718415ca59ef1da7f384e0e797d70ef66b4d6fa

See also related ticket: https://sourceforge.net/p/flightgear/codetickets/2362/ : the fix for that, caused this bug, so I've done a revert of that fix, since the original issue seems fixed 'correctly' now.