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):
- Load a page taller than the viewport, scroll it to
window.scrollY = 500 via JS, wait two animation frames for that to settle.
- 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().
- 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."
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'sN_SendMouseWheelEventpasses the raw AWTMouseWheelEvent.getWheelRotation()/getUnitsToScroll()value straight through as CEF'sdeltaYwith no sign adjustment:AWT's convention (positive
wheelRotation= wheel rotated away from the user, the everyday "scroll down" gesture) is the opposite sign of whatCefMouseEvent'sdeltaYexpects 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, seeplan/findings.md).Repro
Added
java/tests/junittests/UpstreamIssue26Test.java(currently@Disabledwith a link to this issue, so it doesn't fail the normal suite -- remove@Disabledto re-run it):window.scrollY = 500via JS, wait two animation frames for that to settle.java.awt.event.MouseWheelEventto the OSR browser's UI component with a positivegetWheelRotation()(AWT's "scroll down" convention) viaComponent.dispatchEvent().window.scrollYincreases (scrolls further down). Actual: it decreases (confirmed:500.0026550292969->450.1028747558594for one repro run) -- the page scrolled up instead.Fix sketch (not implemented here)
Negate
delta(or the resultingdeltaY/deltaX) before passing it toCefMouseEvent/SendMouseWheelEventinnative/CefBrowser_N.cpp'sN_SendMouseWheelEvent, matching the community fix already proposed upstream. Should be verified against bothWHEEL_UNIT_SCROLLandWHEEL_BLOCK_SCROLLscroll 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."