bugfix(input): Fix touchpad upward scrolling in UI list boxes

[afc-afc0]

Summary

• Fixes touchpad upward scrolling in UI list boxes (GadgetListBox) where the list momentarily scrolls up then jumps back down - Preserves wheel delta sign when normalizing, so touchpad's small continuous deltas are no longer truncated to 0 and misidentified as downward scroll
• Mouse wheel behavior is completely unchanged

Root Cause

In Mouse::createStreamMessages(), the wheel delta was divided by MOUSE_WHEEL_DELTA (120) before being sent as a message argument.
Touchpad devices send small deltas (e.g. +30) that truncate to 0 on integer division. In WindowXlat.cpp, the direction check if (argument > 0) maps 0 to GWM_WHEEL_DOWN, causing upward touchpad scroll to be treated as downward.

Fix

Clamp the normalized wheel delta to at least 1 or -1 based on the original sign of wheelPos, ensuring the scroll direction is
always preserved. Only Mouse.cpp is changed — no consumers need modification.

Test plan

• Verified mouse wheel scrolls up and down correctly in UI list boxes
• Verified mouse wheel zoom in/out works correctly on the map
• Verified no regression in combo box scrolling
• Verified touchpad upward scrolling no longer jumps back down

[greptile-apps]

Greptile Summary

This PR fixes a bug where touchpad devices sending small wheel deltas (e.g. +30) would have their values truncated to 0 by integer division, causing WindowXlat.cpp's argument > 0 direction check to misidentify upward scrolls as downward. The fix clamps the normalized tick count to at least ±1 based on the sign of the original wheelPos, correctly preserving scroll direction with no change to standard mouse wheel behaviour.

Confidence Score: 5/5

Safe to merge — the fix is minimal, logically correct for all delta values, and preserves existing mouse wheel behaviour.

The change is a single expression that correctly handles all four cases: small positive touchpad delta (clamps to +1), small negative touchpad delta (clamps to -1), and standard wheel multiples of 120 (unchanged). The wheelPos != 0 guard ensures the zero case is never reached. No consumers need modification, and the fix directly addresses the documented root cause without introducing new edge cases.

No files require special attention.

Important Files Changed

Filename	Overview
Core/GameEngine/Source/GameClient/Input/Mouse.cpp	Clamps normalized wheel ticks to ±1 minimum based on original wheelPos sign, fixing direction detection for small touchpad deltas that previously truncated to 0

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["WM_MOUSEWHEEL\nwheelPos e.g. +30 (touchpad) or +120 (mouse)"] --> B["Mouse::createStreamMessages()"]
    B --> C{"wheelPos != 0?"}
    C -- No --> D["Skip wheel message"]
    C -- Yes --> E["wheelTicks = wheelPos / MOUSE_WHEEL_DELTA (120)"]
    E --> F{"wheelPos > 0?"}
    F -- Yes --> G["max(1, wheelTicks)\ne.g. max(1, 0) = 1"]
    F -- No --> H["min(-1, wheelTicks)\ne.g. min(-1, 0) = -1"]
    G --> I["appendIntegerArgument(1)"]
    H --> J["appendIntegerArgument(-1)"]
    I --> K["WindowXlat: argument > 0?\n1 > 0 → true → GWM_WHEEL_UP ✓"]
    J --> L["WindowXlat: argument > 0?\n-1 > 0 → false → GWM_WHEEL_DOWN ✓"]

Loading

_{Reviews (1): Last reviewed commit: "bugfix(input): Fix touchpad upward scrol..." | Re-trigger Greptile}

[DevGeniusCode]

Good catch, closes #2584
I checked mine and it did solve the issue
Need to replicate to vanilla generals

[xezon]

The comment is a bit incomplete. It would be better if it clarified that it now guarantees a non-zero value.

[xezon]

Minor: could be written as.

Int wheelTicks = m_currMouse.wheelPos / MOUSE_WHEEL_DELTA;
wheelTicks = m_currMouse.wheelPos > 0 ? max( 1, wheelTicks ) : min( -1, wheelTicks );
msg->appendIntegerArgument( wheelTicks );

[xezon]

It is not clear to me that this fix proposal is the best approach. Perhaps it would be better to make this message argument a float type instead of integer? It looks like it would be possible. Follow all code at MSG_RAW_MOUSE_WHEEL.