fix: avoid unsafe iOS keyboard dismissal - #957
Merged
Merged
Conversation
|
Size Report
Startup median (7 runs, lower is better):
Top changed chunks:
|
Member
Author
|
Reviewed against #952 and the iOS runner path. This removes the unsafe dismiss swipe/coordinate fallback that could type into focused fields, keeps dismissal limited to safe native controls, and preserves an explicit UNSUPPORTED_OPERATION result when the keyboard stays visible. Docs/help now steer agents away from manual Done/back fallbacks unless intentional, and checks are green. No remaining blockers; marking ready-for-human. |
thymikee
added
the
ready-for-human
thymikee
force-pushed
the
fix/ios-keyboard-dismiss-safe-controls
branch
from
June 30, 2026 12:06
efe667d to
5ea727e
Compare
thymikee
added a commit
that referenced
this pull request
Jul 9, 2026
Review on #1173 flagged the unconditional "does not block" claim as false for targets visually covered by the keyboard: direct-selector press resolution is isHittable-gated and falls through to ELEMENT_NOT_FOUND, the tree path allows non-hittable taps with only a no-visible-effect hint, and bottom-pinned-button-under-keyboard (#291/#469/#957) is a real case where dismissal was the remedy. All three strings (runner hint, help manual-qa, help workflow) now say the keyboard USUALLY does not block presses and name concrete fallbacks: scroll the target into view, or keyboard enter when submission is wanted.
thymikee
added a commit
that referenced
this pull request
Jul 9, 2026
…1173) * fix: guide agents past iOS keyboard dismissal and get-text guesses Tonight's benchmark leaderboard showed two recurring agent-UX misses: keyboard dismiss failing after fill (5x, now the #1 failed command) and get-text guessed as a command name (1x). - iOS keyboardDismiss now returns a hint explaining the on-screen keyboard does not block agent-device interactions, so agents should press the next target directly instead of retrying dismiss, and use keyboard enter only when submission is actually wanted. - help manual-qa and help workflow recovery text no longer teach the false "dismiss to unblock the target" pattern. - The command-suggestion curated map now maps get-text/gettext/get_text to the real get text command shape; the generic edit-distance fallback did not produce any suggestion for these guesses. * fix: soften keyboard guidance for genuinely covered targets Review on #1173 flagged the unconditional "does not block" claim as false for targets visually covered by the keyboard: direct-selector press resolution is isHittable-gated and falls through to ELEMENT_NOT_FOUND, the tree path allows non-hittable taps with only a no-visible-effect hint, and bottom-pinned-button-under-keyboard (#291/#469/#957) is a real case where dismissal was the remedy. All three strings (runner hint, help manual-qa, help workflow) now say the keyboard USUALLY does not block presses and name concrete fallbacks: scroll the target into view, or keyboard enter when submission is wanted.
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.
Summary
Closes #952.
The dismiss-control search intentionally checks matching buttons beyond
app.toolbars.buttonsbecause iOS 26 may expose keyboard-accessoryDonecontrols outside aUIToolbar. It remains bounded by exact safe labels and keyboard-accessory geometry, so it can tap a nearby dismiss control without falling back to input-mutating gestures or raw coordinates.Touched files: 8. Scope stayed within iOS runner keyboard behavior plus related help/docs/tests.
Validation