fix(tauri-plugin-webdriver): resolve pointerMove origin so click(options) hits the target#433
Merged
Merged
Conversation
Contributor
|
Standing release PR: #400 · 12 packages queued · open 67h 24m · ✅ ready to merge Release Preview — 13 packages
These changes will be added to the release PR (#400) when merged: ChangelogProject-wide changesAdded
Changed
Fixed
Removed
@wdio/dioxus-service N/A → 1.1.0Changed
@wdio/electron-cdp-bridge wdio-electron-cdp-bridge@v10.0.0 → 10.1.0Changed
@wdio/electron-service wdio-electron-service@v10.0.0 → 10.1.0Changed
@wdio/flutter-service v1.0.0-next.0 → 1.1.0Added
@wdio/native-cdp-bridge v0.1.0-next.0 → 0.2.0Changed
@wdio/native-mobile-core v1.0.0 → 1.1.0Added
Changed
Fixed
@wdio/native-spy wdio-native-spy@v1.1.0 → 1.2.0Changed
@wdio/native-types wdio-native-types@v2.3.1 → 2.4.0Added
@wdio/native-utils wdio-native-utils@v2.4.0 → 2.5.0Changed
@wdio/react-native-service v1.0.0-next.0 → 1.1.0Added
Fixed
@wdio/tauri-service wdio-tauri-service@v1.1.0 → 1.2.0Fixed
Removed
dioxus-package-test-app v0.1.0 → 0.2.0Changed
tauri-plugin-wdio-webdriver tauri-plugin-wdio-webdriver@v1.1.0 → 1.2.0Fixed
After merge — predicted release
Updated automatically by ReleaseKit |
Contributor
…ons) hits the target element.click(options) routes through the W3C Actions API instead of the elementClick endpoint. The embedded driver's PointerMove ignored the action `origin`, so WebdriverIO's element-relative move (origin=element, x/y=0) was treated as absolute viewport coordinates and landed at (0,0), missing the target. Resolve viewport/pointer/element origins and add Executor::get_element_center (client/viewport coords). Adds an e2e regression test (the repro from #423). Fixes #423 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
eb067cd to
14f48f4
Compare
…enter Address review feedback on get_element_center: scrollIntoView uses behavior 'instant' so getBoundingClientRect is not read mid-animation under scroll-behavior: smooth, and the center uses Math.floor to match the W3C "in-view center point" algorithm (avoids a 1px divergence at sub-pixel element boundaries). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ctions calls Address review feedback: pointer_state was a local reinitialized to (0, 0) at the start of every perform() call, so an origin: "pointer" move in a later performActions call computed from (0, 0) instead of the pointer's actual position. Persist it in the session's ActionState (read at the start of perform, written back at the end) and reset it on release, matching how pressed keys/buttons are tracked. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…d clicks
element.click(options) routes through the W3C Actions API, which the embedded
driver dispatched as bare mousedown/mouseup MouseEvents. Manually dispatched
mouse events don't make the browser synthesize a click, so element click
handlers never fired — .click({}) moved to the right spot (after the origin
fix) but still didn't actually click. Emit a click event after a primary-button
press + release on the same position (a click, not a drag). Real WebDriver
providers (official/crabnebula) already do this; this brings the embedded
driver in line, fixing the e2e on the embedded provider.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ry release Address review feedback: primary_down_pos was reset on every PointerUp regardless of button, so a non-primary release between a primary down and up (button 0 down -> button 1 up -> button 0 up) would drop the press state and suppress the synthesized click. Gate both the click synthesis and the reset on the primary button. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…igins The PointerMove origin match treated any named origin as viewport via a catch-all `Some(Origin::Named(_)) => (*x, *y)`. The W3C Actions spec defines only "viewport" and "pointer" as named origins, so give "viewport" its own arm and return invalid argument for anything else instead of silently falling through to viewport behaviour. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 19, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
element.click(options)(e.g..click({}),.click({ button: 'right' })) silently misses its target on the embedded Tauri driver, while bare.click()works. Reported in #423..click()uses theelementClickendpoint (click_element→ JSel.click(), coordinate-independent)..click(options)instead routes through the W3C Actions API: WebdriverIO sends apointerMovewithorigin= the element reference andx/y= offsets (0,0 by default). The driver'sPointerMovedeserialized onlyx/y/durationand ignoredorigin, so serde dropped it and(0,0)was treated as absolute viewport coordinates → the pointer moved to the top-left corner andpointerDown/Upmissed the element.Fix
actions.rs: addoriginto thepointerMoveaction and resolve it per the W3C Actions spec:"viewport"(or absent, the default) →x/yare absolute viewport coords (unchanged behaviour)"pointer"→ relative to the current pointer position{ "element-6066-…": "<id>" }→ offset from the element's in-view centerexecutor.rs: addExecutor::get_element_center, returning the element's center in client/viewport coordinates viagetBoundingClientRect()(scrolling it into view first). This is intentionally distinct fromget_element_rect, which adds scroll offsets (page coords); pointer events dispatch onclientX/clientY, so viewport coords are required.This also fixes
moveTo, drag, and hover-with-offset — anything that routes throughperformActionswith an origin — not just click.Tests
e2e/test/tauri/actions.spec.ts(the repro from [🐛 Bug]: Tauri plugin fails to executeclick()correctly when arguments are passed #423):.click({})and.click({ button: 'left' })now increment the counter exactly like bare.click().Validation
cargo checkandcargo clippy --all-targetsclean — no new warnings (the twoincompatible_msrvnotes are pre-existing in the cookie/OffsetDateTimepath, unrelated to this change).Fixes #423
🤖 Generated with Claude Code