Input order does not match display order

Scenario: We have a Drawable Hierarchie, as follows:

new CompositeDrawable{
    InternalChildren = new Drawable[]{
        new SomeClickableThing{
        },
        new SomeOtherClickableThing{
            Depth = 1f
        },  
    }
}

Currently IsHovered (as well as everything affected by PositionalInputQueue and buildPositionalInputQueue) will not take Depth into account. This means sometimes you click on Elements that are behind others, if a earlier child has a lower depth value.

This is a limitation I ran into in osu/#21119, which I will now consider as blocked from merging until this issue gets resolved (or my workaround is in a acceptable state). I do have a fix currently in place see this commit, but that causes the Settings of selected Elements to ease-in all of their settings every MouseDragEvent, which is also not ideal. (also just whilst writing this I see that this fix is somewhat stupid. I really only need to run that when the Ordering of Items inside a DrawableList actually changes. That still wouldn’t solve the core issue though.)

I believe this could be solved adding a OrderBy(d => d.Depth) in InputManager. I am not sure of the exact Consequences of this, which is why this is not a pr. https://github.com/ppy/osu-framework/blob/7f7ce8149623f5efcb2cc1110fec1b503b812693/osu.Framework/Input/InputManager.cs#L611

[C0D3-M4513R]

The issue is, that without the linked commit SkinBlueprint’s in the SkinEditor/SkinBlueprintContainer would only get selected in the order they were added. See https://github.com/ppy/osu/pull/21119#issuecomment-1344529992. This demonstrates it really really well. When an item changes it’s position, I simply set the Item depth of the associated SkinBlueprint and SkinBlueprint.Item.

I am going to try and make a simple Test, that demonstrates it in osu.Framework

Edit: Oh. You are the person that sent that Message LUL.

[C0D3-M4513R]

I have started investigating SelectionBlueprint, and think that maybe there is something funky going on there, which prevents IsHovered from being updated. With the above snippets I’m fairly certain, that this is NOT a framework bug. If can prove otherwise, I will reopen.