`TestSceneHitObjectComposer.TestPlacementFailsWhenClickingButton()` was
attempting to cover the case of the user clicking a toolbox button which
was in front of the playfield, and ensure that the click did not result
in a placement. However, since the paddings in
67f83f246b were added, it is impossible
for a toolbox button to be in front of the playfield in the collapsed
state, which the test was relying on.
The test scenario is still however relevant in the case of the toolbox
being expanded, as in that state the toolbux buttons may very well end
up being in front of the playfield, and they still should not result in
a hitobject being placed. To ensure that this is the case, add a few
extra test steps ensuring that the toolbox is expanded first before
trying to retrieve an overlapping button.
Because the online info reset (which includes online ID reset) was
happening after encoding,
`TestSceneBeatmapLeaderboard.TestLocalScoresDisplayOnBeatmapEdit()`
started failing, as the hash no longer matched expectations after the
first save of the map.
The online ID will be reset unconditionally after any local change is
made to any beatmap. That behaviour no longer depends on online lookups
succeeding or failing.
This may change at a later date when beatmap submission is integrated
into lazer - the idea is that online IDs would get re-populated on local
beatmaps once they are submitted to web.
This test scene passes at e58e1151f3 and
fails at current master, due to an inadvertent regression caused by
e72f103c17.
As it turns out, the online lookup flow that was causing UI thread
freezes when saving beatmaps in the editor, was also responsible for
resetting the online ID of locally-modified beatmaps if online lookup
failed.
The `SelectedMods.BindValueChanged()` callback in `ModSelectOverlay` can
in some instances run recursively. This is most heavily leaned on in
scenarios where `SelectedMods` is updated by an external component. In
such cases, the mod select overlay needs to replace the mod instances
received externally with mod instances which it owns, so that the changes
made on the overlay can propagate outwards.
This in particular means that prior to this commit, it was possible to
encounter the following scenario:
modSettingChangeTracker?.Dispose();
updateFromExternalSelection(); // mutates SelectedMods to perform the replacement
// therefore causing a recursive call
modSettingChangeTracker?.Dispose();
// inner call continues
modSettingChangeTracker = new ModSettingChangeTracker(SelectedMods.Value);
// outer call continues
modSettingChangeTracker = new ModSettingChangeTracker(SelectedMods.Value);
This leaks one `modSettingChangeTracker` instance from the inner call,
which is never disposed.
To avoid this, move the disposal to the same side of the recursion that
the creation happens on, changing the call pattern to:
updateFromExternalSelection(); // mutates SelectedMods to perform the replacement
// therefore causing a recursive call
modSettingChangeTracker?.Dispose();
// inner call continues
modSettingChangeTracker = new ModSettingChangeTracker(SelectedMods.Value);
modSettingChangeTracker?.Dispose();
// outer call continues
modSettingChangeTracker = new ModSettingChangeTracker(SelectedMods.Value);
which, while slightly wasteful, does not cause any leaks.
The solution is definitely suboptimal, but addressing this properly
would entail a major rewrite of the mod instance management in the mods
overlay, which is probably not the wisest move to make right now.
