While looking for a workaround, I found that mouse wheel information isn’t completely broken in 2022:
element.RegisterCallback<WheelEvent>((evt) => {
Debug.LogFormat("WheelEvent.delta: {0}, mouseDelta: {1}, Input.GetAxis: {2}",
evt.delta, evt.mouseDelta, Input.GetAxis("Mouse ScrollWheel"));
}
In 2021.x, the output shows that delta.y == mouseDelta.y
:
WheelEvent.delta: (0.00, 3.00, 0.00), mouseDelta: (0.00, 3.00), Input.GetAxis: -1
In 2022.2, delta.y
is always 0
, but mouseDelta.y == Input.GetAxis("Mouse ScrollWheel")
:
WheelEvent.delta: (0.00, 0.00, 0.00), mouseDelta: (0.00, 1.00), Input.GetAxis: 1
Also a little interesting: with mice that allow left/right inputs on the wheel, this does NOT appear to trigger a WheelEvent
in Unity 2021.x, but in 2022.2 it does fire with a non-zero value in mouseDelta.x
(both delta
and Input.GetAxis
were zero).
In our custom elements which relied on mouse wheel input, we had previously been using WheelEvent.delta.y
, but it seems we can safely change this to mouseDelta.y
(although the magnitude is different so we’ve got to adjust our sensitivity settings).
It’s not clear to me whether this is an expected breaking change and everything (including Unity-provided UIElements like the ScrollView) should switch over to using mouseDelta
(according to the official documentation it seems we should still expect delta
to be the way to go), but this also means that it’s possible to implement a (hacky) workaround for the time being (but if in a future release ScrollView starts to scroll on its own again, I fully expect this to cause problems):
listView = root.Q<ListView>("ListView");
var sv = listView.Q<ScrollView>();
sv.RegisterCallback<WheelEvent>((evt) =>
{
sv.scrollOffset -= evt.mouseDelta * 10f;
});