test(ios): keep status notes on screen for the paste-control UI test - #151
Merged
Merged
Conversation
testPasteControlTapSavesPasteboardContent failed on the hosted runner while the paste itself succeeded: the failure hierarchy already held the history row for the sample text (17 s old) and the durable "Saved" chip, and the recording shows the row at 0 s two seconds after the tap. What the test never saw was the `save-note` chip, which flashes for two seconds; with code coverage on, the hosted runner takes longer than that between two accessibility snapshots, so `waitForExistence` missed a note that did show. Locally the whole test runs in under eight seconds and always caught it. - New DEBUG launch argument `-ui-test-keep-save-notes`: `flashNote` skips only the two-second dismissal, so a real note stays until the next one replaces it. What is noted, and when, is unchanged. - The test launches with it, waits generously (the runner is slow and existence polling samples about once per second), and now also asserts the durable outcome: the pasted text as a `clip-row`. Verified locally on an erased iPhone 17 simulator; the test self-skips when the simulator pasteboard already holds content synced from the Mac.
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
1 participant
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.
Root cause
CaptureFlowUITests.testPasteControlTapSavesPasteboardContentfailed on the hosted iOS runner (run 35135515537 twice onfeat/ocr-entity-chips, and a control dispatch ofmain) while passing locally. The evidence in the run's xcresult shows the paste itself succeeded: the accessibility hierarchy captured at the failure already held theclip-rowfor "gancho paste-drive sample" (17 s old) and the durable "Saved" chip, and the screen recording shows the row at 0 s two seconds after the tap. What the test never observed was thesave-notechip, whichflashNotedismisses after 2 s: with-enableCodeCoverage YESthe hosted runner takes longer than that between two accessibility snapshots (the test took 26 s there vs 7.5 s locally), sowaitForExistence(timeout: 8)only sampled after the note was gone.Fix
-ui-test-keep-save-notes:flashNoteskips only its two-second dismissal, so a real note stays until the next one replaces it. What is noted, and when, is unchanged.Verification
make lint: 0 violations.make test: 1,138 tests in 169 suites.make test-ui-ios: 13 tests, 0 failures. The paste test self-skips when the simulator pasteboard already holds content synced from the Mac, so it was re-run on an erased iPhone 17 simulator and passed.ui-tests.ymlon this head, run 35143392167: iOS 13 tests, 0 failures, including the paste-control test; macOS UI green.