Open Bug 2086540 Opened 18 days ago Updated 13 days ago

Wheel scroll action has no effect when it follows a previous wheel scroll on another page with async wheel events enabled

Categories

(Remote Protocol :: Agent, defect, P3)

defect
Points:
2

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webdriver:m22])

Attachments

(1 file)

When remote.events.async.wheel.enabled is true, a wheel scroll action does not reach its target when another wheel scroll action ran on a previously loaded page shortly before. No wheel event is dispatched to the target element and the scroll position does not change.

Only the first wheel scroll action in a session works reliably. Waiting about 3s before the action makes it pass, which suggests that the wheel transaction from the previous action is still active and keeps the previous (now gone) scroll target, even across a navigation. That is in the range of mousewheel.transaction.timeout (1500ms).

With remote.events.async.wheel.enabled set to false the same actions work as expected.

Steps to reproduce:

  1. Load a page with a small scrollable element, e.g.:
    <div id="scroller" style="width: 100px; height: 100px; overflow: auto"><div style="width: 300px; height: 300px"></div></div>
  2. Perform a wheel scroll action with the element as origin and deltaY=20.
  3. Navigate to the same page again (new document) and repeat the wheel scroll action within ~1.5s.

Actual results:
The second action does not dispatch a wheel event to the scroller and scrollTop stays at 0.

Expected results:
The second action dispatches a wheel event and scrollTop becomes 20.

This can be reproduced with the new test_scroll_snaps_in_intended_direction wdspec tests as attached to this bug.

./mach wpt --headless testing/web-platform/tests/webdriver/tests/bidi/input/perform_actions/wheel.py --setpref remote.events.async.wheel.enabled=true

Existing tests like test_scroll_direction are not affected because the test preceding them does not scroll, and tests using a new tab are not affected either.

This currently only affects the tier-3 remote_async CI variant, since wdspec tests run with async wheel events disabled by default. It blocks enabling async wheel events for wdspec by default.

Severity: -- → S3
Points: --- → 2
Priority: -- → P3
Whiteboard: [webdriver:m22]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: