[BUG] iOS WebView inputText cannot focus/type after successful tapOn

[genesiscz]

[BUG] iOS simulator (WDA) cannot focus/type into WebView login fields although fields are visible in hierarchy

First of all: huge thanks to the maintainers for this project.
maestro-runner is awesome and very promising. 👍👍👍

I’m reporting a reproducible iOS issue where tapOn succeeds on WebView login fields, but inputText still fails because no editable field is considered focused.

---

Environment

• Host OS: macOS (Apple Silicon)
• maestro-runner: 1.0.9
• Driver: iOS WDA (--platform ios)
• Device: iOS Simulator (iPhone 17 Pro Max, iOS 26.2)
• App under test: React Native (Expo dev client)
• Metro started with localhost host mode (expo start --dev-client --host localhost)

---

What fails

In a login WebView (mepas.cez.cz):

1. tapOn: text="E-mail" succeeds
2. tapOn: text="Heslo" succeeds
3. tapOn: text="Přihlásit se" succeeds
4. inputText fails with:
   • context deadline exceeded: no elements match selector

Flow then fails waiting for the app home tab.

---

Minimal reproduction pattern

appId: "<redacted-app-id>"
---
- launchApp:
    stopApp: true
    clearState: false
- openLink:
    link: "<redacted-scheme>://e2e/go-home"
    optional: true
- tapOn:
    id: "auth-login-button"
    optional: true
- tapOn:
    text: "Continue"
    optional: true
- tapOn:
    text: "E-mail"
    optional: true
- inputText:
    text: "example@example.com"
    optional: true
- tapOn:
    text: "Heslo"
    optional: true
- inputText:
    text: "secret"
    optional: true
- tapOn:
    text: "Přihlásit se"
    optional: true

Command:

maestro-runner \
  --platform ios \
  --device <simulator-udid> \
  test \
  --wait-for-idle-timeout 0 \
  login-fast.yaml

---

Why this looks like a focus/keyboard issue

From hierarchy on failing step:

• XCUIElementTypeTextField name="E-mail" is present and visible
• XCUIElementTypeSecureTextField name="Heslo" is present and visible
• But inputView is visible="false" (keyboard not active)
• After successful taps, inputText still cannot type

So runner can discover/tap controls, but input focus does not become active for text entry in this WebView context.

---

What I already tried

• Forcing fresh app process each run (launchApp.stopApp: true)
• Using both point-based and text-based selectors
• Prioritizing selector-based taps before point fallback
• Switching Metro host mode to localhost (127.0.0.1) to avoid bundle connection errors
• Lowering idle wait timeout (--wait-for-idle-timeout 0)

No change: inputText continues to fail in this iOS WebView login.

---

Related issues reviewed

• [BUG] inputText not working correctly #13 (inputText not working correctly) – looked similar but was resolved as flow/onboarding timing
• [BUG] InputText chars are getting skipped #32 (InputText chars are getting skipped) – typing speed issue, not focus acquisition
• [BUG] the tool should use name or label instead of content-desc on iOS #3 (iOS selector handling) – selector resolution improvements already shipped

This report seems different: selectors resolve, taps execute, but editable focus is not activated in WebView.

---

Request / question

Could you advise whether this is a known WDA/WebView limitation in maestro-runner iOS path, or if there is a recommended workaround/flag?

If helpful, I can attach the exact hierarchy XML + screenshot + full runner report bundle.

Thanks again for the great tool and quick issue turnaround. 👍

[genesiscz]

Follow-up data point from additional repro testing:

• I disabled Simulator hardware keyboard (defaults write com.apple.iphonesimulator ConnectHardwareKeyboard -bool NO) so software keyboard could appear.
• Re-ran the same flow with maestro-runner 1.0.9 on the same simulator.
• Result is unchanged: inputText still fails with context deadline exceeded: no elements match selector after successful tapOn on E-mail / Heslo, and flow times out waiting for home.

So this does not appear to be only a "hardware keyboard attached" setting issue on Simulator.

Thanks again for looking into this.

[omnarayan]

@genesiscz We'll look into it, thank you for reporting it. We'll keep you posted on the progress.

[genesiscz]

Update on this thread.

I re-ran the repro step by step and isolated this to the runner/WebView text entry path:

1. Open app/login and reach the auth popup.
2. In hierarchy, both expected fields are present (email + password).
3. Tap and try inputText for each field.

With plain maestro, the flow works reliably on the same simulator/device and credentials env vars.

With maestro-runner 1.0.9, it consistently fails after a successful field tap with:
context deadline exceeded: no elements match selector
This happens even while hierarchy shows the fields. So this seems runner/WDA-specific, not a selector/page-structure issue on our side.

I also tried a clipboard fallback: setClipboard/paste is not supported via WDA (iOS clipboard operations require simctl or a helper app), so no practical gain there.

Appium fallback via maestro-runner --driver appium was also not viable in this setup (session setup/pacing instability and later stale/main-run-loop timeout behavior).

Is there a specific reason to use WDA instead of IDB? Is it viable for the future? And did you ever have success with this workflow using expo-web-browser or a similar browser path?

@omnarayan wow, thanks! Let me know if I can help with any debugging or whatever, happy to help!

[omnarayan]

@genesiscz thanks for digging deeper into this. Let me share where we're coming from and what our plan looks like. I'm not claiming we made the right calls — the whole point is to be open and get honest, brutal feedback. (Also, English isn't my first language and I used AI to polish the writing, but the thoughts are entirely mine.)

We're in the business of enterprise device labs, and recently launched a zero-trust SaaS-based device lab as well. Based on customer demand, we added Maestro support to our offering and started hitting bottlenecks. Our response was to contribute back — PRs for parallel runs, real iOS device support, better reporting — with the idea of making Maestro better while staying focused on our own business.

But we hit a wall. Maestro isn't pure open source in practice — any feature that touches their bottom line or competes with Maestro Cloud tends to get ignored or rejected.

So to actually serve our customers, we built our own implementation. And once we had it, we realized it might be useful to others — so we released it as pure open source, with one promise: no features behind a paywall, ever.

---

Now to your questions — this is what I'd call the "tool maker's paradox." Because we're not end users, we live in a bubble. We don't experience the real pain points firsthand, which is exactly why I couldn't answer your question about expo-web-browser or similar browser flows — we simply haven't faced that use case. But we're committed to addressing it, and we will deliver.

On your question about WDA vs IDB — we were more comfortable with WDA and it handled all the use cases we knew about, so that's what we went with.

---

A few updates that might be useful:

Android driver — We hit limitations in the stock Android driver, so we built our own and it's live. If you're running Android tests, give this a try:

maestro-runner --driver devicelab --platform android test flow.yaml

Desktop browsers — you might be surprised — we've added support, and speed-wise we're actually beating Playwright.

---

What's next: We're redesigning Android WebView and browser support, and after that we're building our own iOS driver.

Your use case matters though — we'll prioritize it ahead of the Android WebView/browser work.