Osu: Changelog Overlay doesn't dim versions if opened from settings/update notification for the first time

[Gabixel]

Describe the bug: If you open the Changelog Overlay for the first time from the version at the bottom of the settings or from the update notification, it doesn't dim the list of other versions in the header.

Screenshots or videos showing encountered issue:
How it's shown:

How it should be shown:

osu!lazer version: 2019.830.0

[bdach]

Also reproduces in visual tests in TestSceneChangelogOverlay on the Show with Lazer 2018.712.0 step... as long as the first show step is temporarily removed, because this happens only the first time the overlay shows up. I'll try to dig and see what might be causing this.

[bdach]

This is a fetch race. Since the first time the changelog is displayed there is an API hit to get a list of available streams, this line in ChangelogHeader fails to update the stream selection, since there aren't any in the Items enumerable yet.

I tried to hook into one of the performAfterFetch continuations to update manually, but weirdly enough there are still no Items at that point, even though the fetch task is supposed to populate them. Feels like I'm missing something, I'll dig in a little more but I figured I'd leave at least this much info, maybe someone more experienced with this codebase can help out here.

[peppy]

Nice deduction looking into this. The true issue lies in TabControl's implementation of Items, which relies on the drawable components of the tab control to provide items back. It is done this way to ensure correctness of order, but in the case here Items is being retrieved immediately after being set, meaning the tab control has not yet updated itself.

Everything in the changelog implementation looks correct (except ShowBuild now being run in performAfterFetch, but this only affects the test).

[Joehuu]

Can't seem to reproduce on 2019.913.0 and above.

[bdach]

Actually did get better in lazer itself, weirdly enough, but the issue still persists for me in the visual tests if you do the temporary step removal as I mentioned above.

[bdach]

This is closer to being fixed now thanks to ppy/osu-framework#2813 being fixed. It would pretty much work out-of-the-box now, except for the fact that the change trigger in performAfterFetch:

https://github.com/ppy/osu/blob/fd121a069c967f59ca83ad1ee65c76df3d9ed5b8/osu.Game/Overlays/ChangelogOverlay.cs#L156

does not get propagated to the bound copy in ChangelogHeader. It could obviously be force-called there too (and that resolves the issue), but I don't consider that the best fix possible, and would instead advocate for a flag that permits forced propagation to other bindables.

If anyone gets to this before I'll have a chance to, it would also be nice to get a test for the original bug - this time it'd be almost free, I'd just refactor TestSceneChangelogOverlay to have actual [Test] cases to split all of the other cases off, and re-instantiate the overlay in [SetUp] so that the bug is reproducible every time (because now it only manifests the first time the overlay is shown). After that all that would be left is just to stick an assertion making sure the selected release stream is highlighted and the rest dimmed.