It was quite easy to dismiss by accident. I've added some positional and
time based lenience with numbers that feel good to me. Open to
discussion on whether both are required and if the numbers feel good.
Going forward, at some point, we'll likely want to standardise this
across to other expand-on-hover elements (like player load overlays).
Addresses https://github.com/ppy/osu/discussions/32368.
Closes https://github.com/ppy/osu/issues/32420.
The failure cause here is that in editor the beatmap version for the
beatmap affected (or... any beatmap, really), is 0 (ZERO). That is
probably a regression from https://github.com/ppy/osu/pull/32315, but
like... can we universally agree that calling that change "a regression"
in any capacity is dumb? Like what was that code *doing* playing dumb
reference games and copying stuff into an arbitrary instance that could
get or not get used later on? And now you have a 50/50 chance of
accessing the *correct* model's field, depending on whether you go via
`BeatmapInfo` or `Beatmap.BeatmapInfo`?
Moving the field to `IBeatmap`, i.e. what is by now - by consensus,
since https://github.com/ppy/osu/pull/28473 - supposed to be the "decoded
and materialised" beatmap, fixes this issue.
I probably should have done this as part of
https://github.com/ppy/osu/pull/28473 but it slipped my mind. Probably
for the better too because this change has rather large chances of
breaking stuff so maybe better to examine it in isolation (via diffcalc
runs or whatever).
For added humour points, you'd say that the field on `BeatmapInfo` was
not `[Ignore]`d, so this is a realm schema change, right? No. As far as
I can tell, it's not. I opened realm studio and `BeatmapVersion` *is not
a listed column` on `Beatmap` models.
I'm also not gonna get into the fact that I think `EditorBeatmap` doing
dumb games with juggling two `BeatmapInfo` references since
https://github.com/ppy/osu/pull/15075 is bad, because I don't think I
have the mental capacity to hotfix this by going down that train of
thought.
`CommentReportButton` is pretty cursed but I guess I can see why it is
like it is. Short of inlining it into `DrawableComment` this is probably
the best escape hatch (which I wouldn't be against doing, by the way,
just not sure it's the most productive use of time unless review
feedback comes in saying that would be a better path forward).
Bit unfortunate that this is code that can be written and do stupid
things. Unsure if additional API protections against this are desired
framework-side.