fix(ios): paste text through WDA clipboard#2628
Conversation
Deploying midscene with
|
| Latest commit: |
bc88ba4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ceecc26d.midscene.pages.dev |
| Branch Preview URL: | https://fix-ios-paste-text-input.midscene.pages.dev |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f9020aee7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const elementId = (await this.getActiveElement()) ?? '0'; | ||
| await this.makeRequest( | ||
| 'POST', | ||
| `/session/${this.sessionId}/wda/element/${elementId}/keyboardInput`, |
There was a problem hiding this comment.
When the default strategy reaches pasteText, it relies on WDA's /wda/element/.../keyboardInput key-modifier endpoint to send Command+V. The Appium XCUITest docs for the underlying mobile: keys API state that this only works on iPad and has no effect on non-iPad iOS devices; because that call can still return successfully, the catch block in IOSDevice.typeText will not run and iPhone inputs can remain blank under the new default paste strategy. Please detect unsupported devices or verify the paste actually changed the focused field before skipping the existing /wda/keys path.
Useful? React with 👍 / 👎.
The default WDA `/wda/keys` path pushes the whole string in a single request, so XCUITest fires keystrokes back-to-back with ~30-50ms gaps. If the input's onChange handler blocks for longer than that gap (RN re-render, predictive bar, autocorrect), every keystroke that lands inside the blocking window is dropped, producing contiguous gaps such as "Al is amazing" arriving as "Al mazing". Send characters one at a time with an inter-key delay so the gap exceeds the typical app reaction window. The new `keyboardTypeDelay` option on `IOSDeviceInputOpt` defaults to 80ms and can be set to 0 to restore the legacy one-shot behavior.
quanru
force-pushed
the
fix/ios-paste-text-input
branch
from
4f9020a to
e59290e
Compare
1 participant
Summary
Split from #2518. This PR contains only the iOS input changes.
keyboardInputStrategyandkeyboardTypeDelayto the iOS device input options.paste, using the WDA pasteboard plus a Cmd+V keyboard shortcut./wda/keyspath behindkeyboardInputStrategy: "type".Why
WDA key typing can drop characters on longer or reactive iOS inputs. Pasting the full text through the pasteboard avoids that contiguous key-delivery failure mode while preserving an explicit type strategy for compatibility.
Test plan
pnpm run lintnpx nx test iosnpx nx test core