a
b
From acde5c0fe4e37e76ef11940026583fd8605f77c2 Mon Sep 17 00:00:00 2001 From: SGavrl <277843151+SGavrl@users.noreply.github.com> Date: Mon, 3 Aug 2026 16:04:18 +0000 Subject: [PATCH] Correct scroll event overflow oracle --- .../obscura-cdp/tests/scroll_event_on_assignment.rs | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/crates/obscura-cdp/tests/scroll_event_on_assignment.rs b/crates/obscura-cdp/tests/scroll_event_on_assignment.rs index 9c930ef..382bae6 100644 --- a/crates/obscura-cdp/tests/scroll_event_on_assignment.rs +++ b/crates/obscura-cdp/tests/scroll_event_on_assignment.rs @@ -11,9 +11,9 @@ //! silently did nothing and scroll-driven feeds stalled after their first batch. //! //! Checked against a real Chrome over CDP with this same probe: assigning -//! `scrollTop` fires exactly one `scroll` event there. These tests assert the -//! same observable behaviour, not the synthetic geometry around it — the offset -//! is intentionally not clamped, since without layout any maximum is a guess. +//! `scrollTop` fires exactly one `scroll` event when the element can actually +//! scroll. The fixture therefore has explicit viewport and content dimensions; +//! Chromium clamps a non-overflowing element to zero and dispatches no event. use obscura_cdp::dispatch::{dispatch, CdpContext}; use obscura_cdp::types::CdpRequest; @@ -29,7 +29,10 @@ async fn serve_once() -> String { tokio::spawn(async move { let mut buf = [0u8; 2048]; let _ = socket.read(&mut buf).await.unwrap(); - let body = "
a
b
a
b