Skip to content

fix(ios): restore the back swipe's pre-swipe still span - #4515

Merged
thymikee merged 4 commits into
mainfrom
fix/ios-back-swipe-stillness
Nov 14, 2026
Merged

thymikee merged 4 commits into
mainfrom
fix/ios-back-swipe-stillness

Conversation

@thymikee

@thymikee thymikee commented Nov 13, 2026 •

Copy link
Copy Markdown
Member

Summary

Follow-up to #4508. iOS back's swipe fallback required the screen to be still for a span derived from the post-swipe delay. When #4508 cut that delay to 0.1 s, the span shrank from about 0.55 s to 0.4 s on a simulator. A screen that repaints itself every 0.4–0.55 s (carousel, pulsing badge) could then look still, and its own repaint after a no-op swipe was read as a successful back. The agent then works on the wrong screen, and a retry can go back twice.

The still span now has its own 250 ms margin, independent of the delay: about 0.55 s on a simulator again. The 0.1 s after-sample and the 0.05 s sampling pause stay. The settle budget derives from the span. The cost is about 0.15 s on swipe-path backs only; the navigation-bar button path is unaffected. 5 files.

Validation

Head 8946026, base ddbfc85.

  • All 36 back runner tests pass on an iPhone 17 simulator (iOS 27.0), including the new one: a screen that repaints every 0.5 s with a no-op swipe, tried at five timer phases, answers back_swipe_unverified. With the old 100 ms span, that test fails (misread as success).
  • macOS runner test build: TEST BUILD SUCCEEDED. check:xctest-selection, focused vitest (109), typecheck, and lint pass.
  • Swipe-path back in Safari history, 8 runs each, from runner trace: settle samples 4 → 5, still time median 422 → 574 ms (+152 ms). After-sample gap unchanged (~320 ms).
  • CI owns check:affected.

🤖 Generated with Claude Code


Autofix with [code]smith
Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.

View guided diff Turn on auto-fix

#4508 cut the post-swipe delay to 0.1 s, and the required still span was
derived from that delay, so it shrank to about 0.4 s on a simulator. A screen
that repaints itself every 0.4-0.55 s could then look still, and its own
repaint after a no-op swipe read as a back.

The still span now uses its own 250 ms margin instead of the delay: about
0.55 s on a simulator again. The 0.1 s after-sample and the 0.05 s sampling
pause stay. The settle budget derives from the span, so it follows.

The slow-toggle fixture repaints every 0.5 s again and runs without the
edge pan, so the swipe is a no-op; back is tried at five timer phases and
must answer back_swipe_unverified each time.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
@github-actions

github-actions Bot commented Nov 13, 2026 •

Copy link
Copy Markdown
Contributor

Size Report

Metric Base Current Diff
Installed (including dependencies) 6.27 MB 6.27 MB +40 B
Package (unpacked) 6.27 MB 6.27 MB +40 B
Package (download) 1.90 MB 1.90 MB +8 B

Startup median (7 runs, lower is better):

Scenario Base Current Diff
CLI --version 35.6 ms 39.0 ms +3.4 ms
CLI --help 84.7 ms 84.9 ms +0.2 ms

@cubic-dev-ai cubic-dev-ai 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.

All reported issues were addressed across 5 files

Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic

@apex-sentinel-staging

apex-sentinel-staging Bot commented Nov 13, 2026 •

Copy link
Copy Markdown

Apex Sentinel · ✅ Approve

Since the last review: 0 new · 0 still open · 0 no longer raised

No open findings.

Reviewed with this repository's own Sentinel configuration (ddbfc855661f).

💬 Talking to Sentinel

In a finding's thread, reply with:

Command What it does
@apex-sentinel-staging note <context> Adds context; Sentinel re-checks the cited code
@apex-sentinel-staging pivot <why> Says the finding is wrong; Sentinel re-checks the cited code
@apex-sentinel-staging like Marks the finding as useful
@apex-sentinel-staging dislike <why> Marks it as not useful, so it is not raised again

On this conversation, comment @apex-sentinel-staging review to run a full review once again.

Earlier reviews

Review of c5765c4b · 13.11.2026 21:44 UTC

Apex Sentinel · ✅ Approve

Since the last review: 1 new · 0 still open · 1 no longer raised (1 marked fixed)

1 finding(s): 1 minor.

🟡 Minor (1)

Where Finding
website/docs/docs/commands.md:127 🆕 User docs claim the runner tests use a 0.5 s repaint; the fixture repaints every 0.45 s

Reviewed with this repository's own Sentinel configuration (ddbfc855661f).

Review of 8946026c · 13.11.2026 21:06 UTC

Apex Sentinel · ✅ Approve

1 finding(s): 1 minor.

🟡 Minor (1)

Where Finding
apple/runner/AgentDeviceRunner/AgentDeviceRunner/AgentDeviceRunnerAppFixtures.m:788 New 0.5 s repaint fixture leaves the 0.55 s still span only 50 ms of slack, so the test can flake

1 finding below minor hidden (user_settings.min_severity).

Reviewed with this repository's own Sentinel configuration (ddbfc855661f).

@apex-sentinel-staging apex-sentinel-staging Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Apex Sentinel: 1 new finding on 8946026. The verdict and the full list are in the summary comment.

The `--slow-toggle` fixture now repaints on whole multiples of 0.45 s of
the wall clock, which the test process shares, so the test waits for each
target offset (0, 0.09, 0.18, 0.27, 0.36 s) instead of cumulative sleeps.
The 0.45 s period leaves 100 ms below the ~0.55 s still span and stays
above the old ~0.4 s span. The shade steps through 8 grays by wall-clock
period, so samples on either side of a capture stall cannot alias.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

@cubic-dev-ai cubic-dev-ai 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.

All reported issues were addressed across 2 files (changes from recent commits).

Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic

@apex-sentinel-staging apex-sentinel-staging Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Apex Sentinel: 1 new finding on c5765c4. The verdict and the full list are in the summary comment.

Comment thread website/docs/docs/commands.md Resolved
@thymikee

Copy link
Copy Markdown
Member Author

This PR is ready from the code side at 8dfb672: I found no problems in the restored still span. CI was still running when I checked, so no job has a failure to attribute yet. Smoke Tests (ios) is the job that overlaps this change, because the span governs the swipe-fallback back and the settle loop. Smoke Tests (macos) overlaps only through the shared runner build. Numeric Ranges and Coverage run no TypeScript from this diff. There are no conflicts. Before merge, Smoke Tests (ios), Smoke Tests (macos), Numeric Ranges, Coverage and the external review check need to finish green.

Not blocking, and you can take or leave these: (1) the PR body's cost of about 0.15 s per swipe-path back is a simulator figure with 0.1 s captures, and on a device with 0.4 s captures the formula gives about +0.45 s, so scoping that sentence to the simulator would be more accurate; (2) the new doc line on backSwipeVerificationDelay says the still span does not depend on it, but backSwipeGapIsCovered still refuses a swipe when the gap exceeds the stable time, so the comment could say the span stays above the credited gap while the delay is at most the margin; (3) the XCTAssertEqual(required, ...) line in testBackSwipeRequiredStillSpanOutlastsAHalfSecondRepaint restates the production formula, and the three inequalities beside it already pin the behavior; (4) RUNNER_PROTOCOL.md could say that repaints slower than the span are covered only by the swipe's own change check, so users verify with a snapshot; (5) the PR body still shows head 8946026 and a 0.5 s fixture, so the Validation block could match the current head and the 0.45 s fixture.

I could not run Xcode or XCTest. The five-phase test result comes from your thread replies, and no physical-device run exists. The 1.05 s span and 1.4 s settle time are derived from the formula and the earlier capture measurement.

Of the earlier review threads, these no longer apply and can be resolved: the cumulative-phase concern (#4515 (comment)) because every attempt now waits for the wall-clock offset; the 50 ms slack concern (#4515 (comment)) because the fixture period is 0.45 s and a unit test pins the 100 ms margin; the floor shade concern (#4515 (comment)) because a late callback now keeps its own slot; and the commands.md wording concern (#4515 (comment)) because the docs now match the 0.45 s fixture.

@thymikee thymikee added the ready-for-human Valid work that needs human implementation, judgment, or maintainer merge label Nov 13, 2026
@thymikee
thymikee merged commit 2cd1248 into main Nov 14, 2026
22 checks passed
@thymikee
thymikee deleted the fix/ios-back-swipe-stillness branch November 14, 2026 07:28
thymikee added a commit that referenced this pull request Nov 14, 2026
* origin/main:
  fix(android): carry an empty text on a node labelled by its content description (#4531)
  fix(ios): restore the back swipe's pre-swipe still span (#4515)
  fix(daemon-client): type the remote daemon refusal with its dispatch fact (#4532)
  fix: prepare reinstall artifacts before removing apps (#4533)
  fix(ios): classify the keyboard dismiss refusal by what it dispatched (#4536)
  fix(ios): press the navigation bar back button and speed up the back swipe (#4508)
  refactor(gestures): one owner for the densified gesture path; drop the unproven sendevent transport (#4239)
  fix(host-kit): keep Linux process identity stable across clock steps (#4438)
  fix(ios): bound the idle wait of keyboard dismiss and keyboard enter (#4454)
  fix(device-selection): fail an ambiguous device request with only the tied devices (#4506)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-human Valid work that needs human implementation, judgment, or maintainer merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant