Observed on Linux, driving a logged-in linkedin.com/in/<account> profile over CDP: HumanMouse::scroll / CdpMouse::wheel return Ok(()) and the wheel events are dispatched, but the page does not move.
Likely cause
CdpMouse::wheel dispatches Input.dispatchMouseEvent{type: mouseWheel} at the current cursor position:
https://github.com/dashn9/rustenium/blob/main/rustenium/src/input/cdp/mouse.rs#L249
let (x, y, buttons) = {
let s = self.state.lock().unwrap();
(s.position.x, s.position.y, s.buttons)
};
That position starts at (0.0, 0.0) (input/cdp/mouse.rs:46) and is only ever updated by an explicit move (input/cdp/mouse.rs:119-120). Chrome applies a wheel event to the scroll container under that point — so until something has moved the pointer, every scroll is aimed at the very top-left pixel of the viewport.
On a LinkedIn profile that pixel sits under the fixed global nav bar, which is not a scroll container, so the wheel is delivered and correctly does nothing. Any page whose top-left corner is a fixed or otherwise non-scrolling element should reproduce it; a plain document scrolls fine, which is why this does not show up in ordinary use.
Nothing in that path is platform-specific, so it may well reproduce off Linux too — Linux is just where it was hit.
Repro
- Open a logged-in
linkedin.com/in/<account>.
- Call
human_mouse().scroll(600, 0, &context) without moving the pointer first.
- Page does not move.
window.scrollY stays 0.
- Move the pointer into the page body first, then scroll again — it moves.
Suggested fix
Aim the wheel at the middle of the viewport rather than at the last known pointer position when nothing has moved the pointer yet — or let MouseWheelOptions carry an explicit point. Defaulting the initial position to (0, 0) is the part that makes an untouched session scroll at a corner nobody meant.
Related but distinct: #9 is about the end of a scroll snapping back; this one is about the scroll never applying at all.
Observed on Linux, driving a logged-in
linkedin.com/in/<account>profile over CDP:HumanMouse::scroll/CdpMouse::wheelreturnOk(())and the wheel events are dispatched, but the page does not move.Likely cause
CdpMouse::wheeldispatchesInput.dispatchMouseEvent{type: mouseWheel}at the current cursor position:https://github.com/dashn9/rustenium/blob/main/rustenium/src/input/cdp/mouse.rs#L249
That position starts at
(0.0, 0.0)(input/cdp/mouse.rs:46) and is only ever updated by an explicit move (input/cdp/mouse.rs:119-120). Chrome applies a wheel event to the scroll container under that point — so until something has moved the pointer, every scroll is aimed at the very top-left pixel of the viewport.On a LinkedIn profile that pixel sits under the fixed global nav bar, which is not a scroll container, so the wheel is delivered and correctly does nothing. Any page whose top-left corner is a fixed or otherwise non-scrolling element should reproduce it; a plain document scrolls fine, which is why this does not show up in ordinary use.
Nothing in that path is platform-specific, so it may well reproduce off Linux too — Linux is just where it was hit.
Repro
linkedin.com/in/<account>.human_mouse().scroll(600, 0, &context)without moving the pointer first.window.scrollYstays 0.Suggested fix
Aim the wheel at the middle of the viewport rather than at the last known pointer position when nothing has moved the pointer yet — or let
MouseWheelOptionscarry an explicit point. Defaulting the initial position to(0, 0)is the part that makes an untouched session scroll at a corner nobody meant.Related but distinct: #9 is about the end of a scroll snapping back; this one is about the scroll never applying at all.