Version
1.63.0-next (checked on main at 4c6ee93; present since the API was added in aacd8e6)
Steps to reproduce
await device.input.swipe({ x: 100, y: 100 }, [{ x: 100, y: 500 }], 10);
I do not have an Android device to demonstrate the gesture itself, so this is reported from the
source rather than from a recording. The drop is visible statically at every layer.
Expected behavior
The gesture starts at from. types.d.ts documents it as "The point to start swiping from", and
describes segments as "Points following the from point in the swipe gesture", so from is part
of the path.
Actual behavior
from is accepted and then discarded. The swipe starts at segments[0] instead.
packages/playwright-core/src/client/android.ts:337
async swipe(from: types.Point, segments: types.Point[], steps: number) {
await this._device._channel.inputSwipe({ segments, steps }, kNoTimeout);
}
packages/protocol/spec/android.yml:172 has no from field:
inputSwipe:
title: Swipe
parameters:
segments:
type: array
items: Point
steps: int
and the driver builds its Point[] from segments alone
(server/android/driver/.../InstrumentedTest.java:285), then calls device.swipe(segments, steps).
The sibling method four lines below does forward it, which is what makes this look like an
oversight rather than a choice:
async drag(from: types.Point, to: types.Point, steps: number) {
await this._device._channel.inputDrag({ from, to, steps }, kNoTimeout);
}
and inputDrag in the same Java file does parsePoint(params, "from").
Additional context
Two ways to resolve it and I did not want to guess which you would want:
- The docs are right and the code is wrong. Smallest fix is client side and needs no protocol or
driver change, since from is just the first point of the path:
inputSwipe({ segments: [from, ...segments], steps }).
- The code is right and the docs are wrong, in which case
from is redundant with segments[0]
and the parameter documentation should say so.
Happy to send option 1 if that is the call, though I should say plainly that I have no Android
device, so I could verify the plumbing but not the resulting gesture. If you would rather that were
tested on real hardware before landing, completely understand.
sorry if this is a low-priority corner, it turned up while I was reading the client layer. the part
I am least sure of is whether UiDevice.swipe treats the first point as the origin the way I am
assuming. freshman in college, still filling in the gaps :)
Environment
System:
OS: macOS 26.5.2
CPU: (10) arm64 Apple M4
Binaries:
Node: 26.0.0
npm: 11.12.1
npmPackages:
playwright monorepo at main (1.63.0-next)
Version
1.63.0-next (checked on main at 4c6ee93; present since the API was added in aacd8e6)
Steps to reproduce
I do not have an Android device to demonstrate the gesture itself, so this is reported from the
source rather than from a recording. The drop is visible statically at every layer.
Expected behavior
The gesture starts at
from.types.d.tsdocuments it as "The point to start swiping from", anddescribes
segmentsas "Points following thefrompoint in the swipe gesture", sofromis partof the path.
Actual behavior
fromis accepted and then discarded. The swipe starts atsegments[0]instead.packages/playwright-core/src/client/android.ts:337packages/protocol/spec/android.yml:172has nofromfield:and the driver builds its
Point[]fromsegmentsalone(
server/android/driver/.../InstrumentedTest.java:285), then callsdevice.swipe(segments, steps).The sibling method four lines below does forward it, which is what makes this look like an
oversight rather than a choice:
and
inputDragin the same Java file doesparsePoint(params, "from").Additional context
Two ways to resolve it and I did not want to guess which you would want:
driver change, since
fromis just the first point of the path:inputSwipe({ segments: [from, ...segments], steps }).fromis redundant withsegments[0]and the parameter documentation should say so.
Happy to send option 1 if that is the call, though I should say plainly that I have no Android
device, so I could verify the plumbing but not the resulting gesture. If you would rather that were
tested on real hardware before landing, completely understand.
sorry if this is a low-priority corner, it turned up while I was reading the client layer. the part
I am least sure of is whether
UiDevice.swipetreats the first point as the origin the way I amassuming. freshman in college, still filling in the gaps :)
Environment