Skip to content

fix: align Maestro swipe semantics across platforms#1179

Merged
thymikee merged 4 commits into
mainfrom
fix/maestro-android-gesture-timing
Jul 10, 2026
Merged

fix: align Maestro swipe semantics across platforms#1179
thymikee merged 4 commits into
mainfrom
fix/maestro-android-gesture-timing

Conversation

@thymikee

@thymikee thymikee commented Jul 10, 2026

Copy link
Copy Markdown
Member

Summary

Preserve authored Maestro percentage coordinates through a shared core frame-bounds helper and route directional screen swipes through core gesture presets.
Match Maestro iOS synthesized swipe timing while preserving continuous timing for pan and fling; keep non-idempotent assertion recovery Android-only.
Delegate Android helper builds to the clean packaging scripts and document helper-backed Android verification.

Validation

  • react-native-pager-view Android API 36 Debug/Metro: 9/9 Maestro flows passed in 208.4s; one cold-boot launcher retry.
  • react-native-pager-view iOS 26.2 Debug/Metro: 9/9 Maestro flows passed in 179.2s; one PagerView dynamic-page mutation retry.
  • Upstream Maestro 2.5.1 and agent-device both pass focused pager_basic/nested flows on iOS 26.2; both reproduce the PagerView/iOS 18.6 product limitation.
  • pnpm check:quick, pnpm check:tooling, pnpm check:fallow --base origin/main, pnpm build, pnpm build:android, and pnpm build:xcuitest.
  • Provider integration: 120/120; focused post-rebase regression/provider suite: 257/257.
  • Coverage tests: 3,679/3,679 passed locally; the instrumented run hit the existing screenshot retry slow-test gate under host load.

@github-actions

github-actions Bot commented Jul 10, 2026

Copy link
Copy Markdown

Size Report

Metric Base Current Diff
JS raw 1.6 MB 1.6 MB -943 B
JS gzip 517.9 kB 517.6 kB -322 B
npm tarball 624.2 kB 624.4 kB +198 B
npm unpacked 2.2 MB 2.2 MB +2.2 kB

Startup median (7 runs, lower is better):

Scenario Base Current Diff
CLI --version 27.4 ms 29.0 ms +1.6 ms
CLI --help 57.1 ms 57.7 ms +0.5 ms

Top changed chunks:

Chunk Raw diff Gzip diff
dist/src/session.js -864 B -297 B
dist/src/tv-remote.js -178 B -51 B
dist/src/internal/daemon.js 0 B +10 B
dist/src/registry.js 0 B -9 B
dist/src/reporting.js 0 B +7 B

@github-actions

github-actions Bot commented Jul 10, 2026

Copy link
Copy Markdown
PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-07-10 14:42 UTC

@thymikee

Copy link
Copy Markdown
Member Author

Review — 🟢 SHIP-WITH-NITS

The substantive change is a clean one-line guard in maestroHorizontalContentSwipeLanePercent: content-lane remapping (to lane 65) now fires only when the swipe sits on the midpoint (y1 === 50 && y2 === 50) rather than on any equal-Y horizontal swipe. This correctly distinguishes an authored non-midpoint lane (preserve it) from the defaulted/directional midpoint (remap). The rest is docs (AGENTS.md) and a build:android convenience script.

Verified:

  • No falsy-zero bug. The guard is an explicit y1 !== 50 || y2 !== 50, not a truthiness test. An authored y=0 evaluates 0 !== 50 → true, so lane 0 is correctly preserved, not read as "unset." Inputs are pre-validated via Number + Number.isFinite.
  • Prior stabilization (a388535) preserved. resolveDirectionalScreenSwipe calls the helper with literal startX, 50, endX, 50, so left/right screen swipes still land on lane 65. No regression.
  • Both tests pin the exact split: midpoint (y=50,50 → 390 = 65%×600) and new explicit (y=30,30 → 180 = 30%×600).

Nits:

  1. src/compat/maestro/runtime-interactions.ts:410 — an explicitly authored horizontal swipe at exactly y=50 is still forced to lane 65, indistinguishable from the default. Documented in the PR body; worth a one-line comment on the === 50 midpoint intent.
  2. runtime-interactions.ts:412 (maestroPercentSwipeMarginPx) — the sibling iOS-margin helper still uses the old y1 !== y2 "any equal Y" form while this new helper uses === 50. Different platform/purpose so not a bug, but the two "midpoint" definitions now diverge and could confuse a future reader.
  3. package.json:97 (build:android) — unlike package:android-multitouch-helper:npm, the new script does not rm -rf …/dist before repackaging, so stale artifacts could linger. Low severity.

Minimal, correct, no falsy-zero trap, no regression of the earlier gesture stabilization.

🤖 Generated with Claude Code

@thymikee thymikee added ready-for-human Valid work that needs human implementation, judgment, or maintainer merge in-progress Work is actively in progress and removed ready-for-human Valid work that needs human implementation, judgment, or maintainer merge labels Jul 10, 2026
@thymikee thymikee force-pushed the fix/maestro-android-gesture-timing branch from daff7d7 to bb51342 Compare July 10, 2026 13:30
@thymikee thymikee changed the title fix: preserve explicit Android Maestro swipe lanes fix: align Maestro swipe semantics across platforms Jul 10, 2026
@thymikee

Copy link
Copy Markdown
Member Author

Addressed the three nits from the earlier review on the current head:

  • Removed maestroHorizontalContentSwipeLanePercent; explicit authored percentages are preserved through the shared core frame-bounds helper.
  • Removed maestroPercentSwipeMarginPx; semantic directional swipes now use core presets, with no Maestro platform lane/margin heuristics.
  • build:android now delegates to package:android-snapshot-helper:npm and package:android-multitouch-helper:npm; both scripts clear their dist directories before packaging.

No unresolved inline review threads remain.

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

Open in Devin Review

@thymikee thymikee merged commit f53d572 into main Jul 10, 2026
23 checks passed
@thymikee thymikee deleted the fix/maestro-android-gesture-timing branch July 10, 2026 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

in-progress Work is actively in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant