[Bug]: AndroidInput.swipe() silently ignores its documented 'from' point #42348

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:

1. 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 }).
2. 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)