OSR mouse wheel scroll direction is inverted (matches upstream #26) #14

Summary

Confirmed locally, reproduces on this fork's current CEF version (146.0.10+g8219561+chromium-146.0.7680.179): matches upstream chromiumembedded/java-cef#26, open since 2014, with reproductions reported as recent as CEF 90+. A one-line community-proposed fix (negate the wheel rotation) was posted in the upstream thread years ago but never merged.

native/CefBrowser_N.cpp's N_SendMouseWheelEvent passes the raw AWT MouseWheelEvent.getWheelRotation()/getUnitsToScroll() value straight through as CEF's deltaY with no sign adjustment:

double deltaX = 0, deltaY = 0;
if (cef_event.modifiers & EVENTFLAG_SHIFT_DOWN)
  deltaX = delta;
else
  deltaY = delta;

browser->GetHost()->SendMouseWheelEvent(cef_event, deltaX, deltaY);

AWT's convention (positive wheelRotation = wheel rotated away from the user, the everyday "scroll down" gesture) is the opposite sign of what CefMouseEvent's deltaY expects for the same gesture. Result: scrolling down with the mouse wheel scrolls the page up, and vice versa, in OSR mode specifically (upstream comments note windowed/non-OSR mode has the correct direction, but a separate, already-tracked shutdown issue -- this fork's own testing avoids windowed mode for that reason, see plan/findings.md).

Repro

Added java/tests/junittests/UpstreamIssue26Test.java (currently @Disabled with a link to this issue, so it doesn't fail the normal suite -- remove @Disabled to re-run it):

1. Load a page taller than the viewport, scroll it to window.scrollY = 500 via JS, wait two animation frames for that to settle.
2. Dispatch a synthetic java.awt.event.MouseWheelEvent to the OSR browser's UI component with a positive getWheelRotation() (AWT's "scroll down" convention) via Component.dispatchEvent().
3. Expected: window.scrollY increases (scrolls further down). Actual: it decreases (confirmed: 500.0026550292969 -> 450.1028747558594 for one repro run) -- the page scrolled up instead.

Fix sketch (not implemented here)

Negate delta (or the resulting deltaY/deltaX) before passing it to CefMouseEvent/SendMouseWheelEvent in native/CefBrowser_N.cpp's N_SendMouseWheelEvent, matching the community fix already proposed upstream. Should be verified against both WHEEL_UNIT_SCROLL and WHEEL_BLOCK_SCROLL scroll types, and against the Shift-held horizontal-scroll path (deltaX), not just the vertical one this repro exercises.

Found via

This fork's coverage-expansion effort (tracked in #5), while triaging upstream's issue tracker for bugs that could become regression tests in this fork's suite per the user's explicit direction to "start harvesting the upstream git issues for problematic tests."