Skip to content

Limrun iOS fill reports success but drops non-ASCII text #3819

Open

Description

@dzlhk

What happened

On a Limrun iOS simulator, fill / typeText reports success and does not insert Chinese. ASCII on the same focused field works. setElementValue inserts the Chinese and the app reads it back.

packages/provider-limrun/src/ios.ts fill() taps the field, sends Cmd-A, then typeText. That is hardware key events. Chinese has no key code, so the call returns "Text typed" and the field is unchanged.

e2e documents locator.fill as setting the value with no key events (pressSequentially is the keystroke path). @e2e-dev/mobile and @e2e-dev/limrun hit this through agent-device.

Reproduction

App: https://github.com/limrun-inc/sample-native-app (simulator build). Field nameField, button greetButton.

  1. lim ios type "Ada" on nameField, tap greetButton.
    Field is Ada. Heading is Hello, Ada!. Log: greeted Ada.
  2. Focus the field, Cmd-A, lim ios type "你好", tap the button.
    CLI prints Text typed. Field stays Ada. Heading stays Hello, Ada!.
  3. Clear the field, lim ios type "你好".
    CLI prints Text typed. Field stays the placeholder Your name.
  4. lim ios type "Hello" on that same field.
    Field becomes Hello.
  5. lim ios set-text "你好" --ax-unique-id nameField, tap the button.
    Field is 你好. Heading is Hello, 你好!. Log: greeted 你好.

Expected

fill should call setElementValue after focus, including for "". Leave type() / pressSequentially on typeText.

Activity

  1. thymikee commented on Oct 20, 2026

    @thymikee
    Member

    Triage: bug; actionable without more input from you. Confirmed on main: the Limrun iOS fill in packages/provider-limrun/src/ios.ts selects with Cmd-A and then sends typeText, which is key events only. Text with no key code is dropped, and the call still reports success. The fix moves fill to setElementValue after focus, including for "". type keeps the key-event path. An agent can pick this up.

  2. mvanhorn commented on Oct 21, 2026

    @mvanhorn
    Contributor

    Fill focused the field, selected its contents with Command-A, and then sent the string as hardware key events. Characters with no key code never become a key event, so they are dropped while the call still succeeds.

    After text-entry focus arrives, fill writes the whole string with one setElementValue call, including an empty string and characters that have no hardware key.

    #3863

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions