[BUG] tapOn fails but executed on emulator

[satishs22]

Description

tapOn fails with a context deadline exceeded HTTP timeout error when attempting to click an element via UIAutomator2, even though the tap visually fires on the emulator, but UIAutomator2 likely hangs sending the HTTP response back. All preceding steps (including inputText on the same screen) complete without issue.

Steps to Reproduce

1. Run command maestro-runner --device emulator-5554 test -e TEST_EMAIL= -e TEST_PASSWORD= .maestro/login/login-success.yaml
2. With the flow file below
3. Observe that all steps pass up through hideKeyboard after password input, then tapOn: id="login-submit-button" fails

Expected Behavior

tapOn should send the click event to the element and the flow should continue to the next assertion.

Actual Behavior

tapOn times out after ~10.5s with:

Failed to tap: send request: Post "http://localhost/session/15870623-ef9b-40ab-9744-54da32fd1639/element/00000000-0000-0017-ffff-ffff00000040/click": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

The element is located (it has a valid element ID in the URL), but the HTTP POST to /click never returns before the client timeout. The tap does appear to execute on the emulator visually, suggesting the click is sent but the response is never received.

Environment

• OS: macOS (Apple Silicon)
• maestro-runner version: 1.0.7
• Executor: UIAutomator2 (via uia2 socket at /tmp/uia2-emulator-5554.sock)
• Device/Simulator: Android Emulator — google sdk_gphone64_arm64, Android SDK 36 (emulator-5554)

Flow File

# Relevant flow file (anonymized if needed)
appId: com.example.app
name: Login Success
commandTimeout: 20000
---
- clearState:
    appId: com.example.app
- launchApp:
    appId: com.example.app
    newSession: true
    permissions:
      all: allow
- extendedWaitUntil:
    visible:
      id: login-email-input
    timeout: 10000
- takeScreenshot: login-screen-loaded.png
- inputText:
    id: login-email-input
    text: 'test@example.com'
- hideKeyboard
- inputText:
    id: login-password-input
    text: 'testpassword'
- hideKeyboard
- tapOn:
    id: 'login-submit-button'   # <-- fails here
- waitForAnimationToEnd:
    timeout: 3000

Error Output

✗ tapOn: id="login-submit-button" (10.5s)
  ╰─ Failed to tap: send request: Post "http://localhost/session/15870623-ef9b-40ab-9744-54da32fd1639/element/00000000-0000-0017-ffff-ffff00000040/click": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Additional Context

maestro-runner.log

report.json

report.html

[omnarayan]

@satishs22 thank you for reporting it, can you share logcat.

[satishs22]

@omnarayan here you go

Pixel-4a-Android-16_2026-03-02_164158.log

[omnarayan]

Hey @satishs22, thanks for the detailed report and the logcat — super helpful!

So here's what's going on:

Root Cause: The W3C /element/{id}/click endpoint in the UIA2 server calls Android's GestureController.performGesture() under the hood, which waits for the UI to go idle before sending back the HTTP response. The problem is — if tapping the login button kicks off a network request or a screen transition that keeps the UI thread busy, that idle wait just hangs there until our HTTP client gives up after 10s.

We do set waitForIdleTimeout: 200ms to cap this, but it looks like Android SDK 36 might have changed something in the framework layer that's breaking this.

Workaround — give one of these a shot:

1. Disable idle waits entirely by passing --wait-for-idle-timeout 0:

   maestro-runner --device emulator-5554 --wait-for-idle-timeout 0 test ...

2. Or set it in your flow YAML header:

   appId: com.example.app
   name: Login Success
   waitForIdleTimeout: 0

Also, quick question — what framework is the app built with? (React Native, Flutter, native Android?) That'll help us understand why the idle state isn't resolving.

We're looking into a proper fix on our end to sidestep this path altogether. Will keep you posted!

[satishs22]

Hi @omnarayan,

First of all thanks for checking on the issue quickly really appreciate it. I tried both the suggested solution but seems like it didn't work, still the same error.

I'm currently using React Native (0.76.9) - Expo , I even tried with the latest version (0.83.2) just incase but it seems like the error still persist.

Maestro Version Used

maestro-runner 1.0.7
  Commit:  dde4fe8
  Built:   2026-02-20T04:17:22Z
  Go:      go1.26.0
  OS/Arch: darwin/arm64

[omnarayan]

@satishs22 - It's difficult to reproduce this on our test app since every app behaves differently. Could you share the APK so we can debug it directly?