skip to content

In Appium, a hybrid pharmacy app's web-view element is not found after a native tap — how do you diagnose the context on Android and iOS?

level: seniorimportance: should knowfreq 55%

answer

  1. one surface answers at a time
  2. read the list before blaming locators
  3. NATIVE_APP is where a session starts
  4. Android names by package, iOS by page id
  5. only NATIVE_APP listed means wiring

basics

~20 s

The session is almost certainly still on the native surface, where the driver cannot see page markup. List the session's contexts, confirm which one is current, switch into the web-view handle, then retry the find.

solid answer

~40 s

Appium answers every command from one surface at a time, and a session starts on the native one, `NATIVE_APP`. Once the refill-reminder app opens its insurance co-pay page inside an embedded web view, the driver still resolves finds against the native tree, so the page's markup is invisible and the error reads like a bad locator. Call `GET /session/:sessionId/contexts` first: on Android you expect `NATIVE_APP` plus a `WEBVIEW_` handle carrying the package of the process hosting the view; on iOS a `WEBVIEW_` handle carrying a numeric page id. Then `POST /session/:sessionId/context` with that handle and retry. If only `NATIVE_APP` comes back, no debuggable web view was detected at all — an Android Chromedriver pairing or an Apple Web Inspector problem, which is a different fix from switching.

code

bash · 6 lines
bash
BASE=http://127.0.0.1:4723
SID=$(cat session-id.txt)
curl -s $BASE/session/$SID/contexts
HANDLE=$(curl -s $BASE/session/$SID/contexts | python3 -c 'import json,sys; print(next(c for c in json.load(sys.stdin)["value"] if c.startswith("WEBVIEW_")))')
printf '{"name": "%s"}' $HANDLE > ctx.json
curl -s -X POST $BASE/session/$SID/context -H 'Content-Type: application/json' -d @ctx.json

go deeper

for a junior

Be ready to say that a session starts on the native surface and that a web element stays invisible until you list the contexts and switch into the web-view handle.

for a middle

Explain what changes at the switch: which tree the driver resolves finds against, and why an Android handle names a hosting package while an Apple one names a page id.

for a senior

Show a diagnosis order — read the contexts, separate a missing handle from a failed switch, and say which problem each branch is — rather than adding waits to a hybrid suite.

for a principal

Own the convention: where switching lives in the framework, how the surface is asserted at screen boundaries, and how handle discovery for Android and iOS stays one contract instead of two dialects.

## Two trees, one answer A hybrid screen is two element trees drawn into the same pixels. In the pharmacy refill-reminder app the reminder schedule, the dose fields and the bottom navigation are native widgets, while the insurance co-pay page reached from **Refill now** is an embedded web view rendering HTML. Both are visible to a human. Only one is addressable by the driver at a time, and which one is the session's **context**. A session begins in the native context, whose handle is `NATIVE_APP`, and stays there until a command changes it. That single fact explains the whole failure. After the native tap succeeds, the driver is still resolving finds against the native hierarchy: Android's view tree read by the UiAutomator2 driver, or Apple's element tree served by WebDriverAgent under the XCUITest driver. The co-pay page's inputs are not late, not hidden and not misnamed — they live in a tree the driver was never asked about. The native source shows one opaque web-view node where the page should be, and every page locator tried against it fails identically. ## Why the symptom argues for the wrong cause The evidence a failing test hands you points away from the truth. A screenshot proves the field is on screen, so "not rendered yet" looks wrong and "bad selector" looks right. Teams rewrite the locator, lengthen the wait, or add a retry, and the suite gets slower without getting greener. Three signals separate a context problem from a locator problem: - The screenshot shows the element but the source of the current surface does not contain it. - Every locator you try against the page fails, not only the fragile one. - Native elements on the same screen, such as the app's own toolbar, still resolve normally. When all three hold, you are on the wrong surface, and no amount of selector work will help. ## The three commands the diagnosis uses - `GET /session/:sessionId/contexts` returns the handles the driver can serve at this moment. It is read-only and costs almost nothing. - `POST /session/:sessionId/context` takes one handle by name and makes it the surface every later command is answered from. - `mobile: getContexts` is an execute method on the Android drivers and on the XCUITest driver; it returns the same contexts with per-view detail such as titles and URLs, which matters as soon as more than one web view is listed. ## What the list means on each platform | | Android (UiAutomator2 or Espresso) | Apple (XCUITest) | |---|---|---| | native handle | `NATIVE_APP` | `NATIVE_APP` | | web handle | `WEBVIEW_` followed by the package of the process hosting the view | `WEBVIEW_` followed by a numeric page id | | across runs | readable and matchable by its suffix | issued when the remote debugger attaches, so discover it every run | | detection tuning | `appium:ensureWebviewsHavePages`, `appium:enableWebviewDetailsCollection` | `appium:webviewConnectTimeout`, `appium:additionalWebviewBundleIds` | Naming the platform is not politeness here. An Android package suffix means nothing on iOS, and an Apple page id is meaningless in the next session, so a diagnosis written for one platform misleads on the other. ## A diagnosis order that does not waste a morning 1. Capture the contexts list at the moment of failure and record it in the test's failure output, so the next reader does not have to reproduce the bug to see it. 2. If the list contains a `WEBVIEW_` handle, the surface is reachable: post it, retry the find, and the defect is a missing switch in the test. 3. If the list contains `NATIVE_APP` only, stop editing the test. No debuggable web view was detected, and that belongs to web-view debug wiring — Android's Chromedriver pairing, Apple's Web Inspector — not to context switching. 4. If the switch itself throws although the handle was listed, the surface is being handed to a helper that failed to start. Native finds continuing to work proves the session is otherwise healthy. 5. If the find works once and fails on rerun, examine which handle was selected rather than the locator: on iOS a remembered page id will not be valid twice. ## What the switch does and does not change - It changes which tree answers finds, source reads and element interactions for the rest of the session, until you switch again. - It does not end the session, restart the app, or discard the state the flow has reached. - It does not remove the native surface: posting `NATIVE_APP` returns to it on both platforms, and a hybrid flow walking back into native screens must do that explicitly. - It does not create a web view, make an undebuggable one debuggable, or change what the app renders. Treat the current context as state the test owns. Switch immediately before the web assertions the refill-reminder flow needs, return to native as soon as the flow does, and assert the surface at each boundary rather than trusting that an earlier switch survived three steps of navigation.

  • How would you keep a long hybrid flow in the refill-reminder app from drifting into the wrong context?
    Treat the context as state the test owns. Enter the web view immediately before the web assertions, post `NATIVE_APP` again as soon as the flow returns to native screens, and assert the current surface at each boundary instead of assuming the last switch survived. Putting the switch inside the page object that needs it stops one step inheriting another step's surface.
  • The Android contexts list shows a `WEBVIEW_` handle but switching into it throws. What do you suspect?
    Not the switch itself. On Android, entering a web view hands finds to a Chromedriver process that has to match the device's WebView build, so the failure is usually pairing or startup, which web-view debug wiring owns. Confirm by staying native: if native finds still work, the session is healthy and only the web surface is unreachable.

A hybrid screen is two overlapping maps of the same room: the driver reads whichever one you hand it, and it will insist a door does not exist because the door is drawn on the other map.

saying these in an interview costs you the question

  • Assumes a visible web element must be findable from the native context
  • Rewrites the selector instead of reading the session's contexts
  • Thinks the same web-view handle string works on Android and iOS
  • Adds a longer wait to fix what is a wrong-surface error
  • Treats a list holding only NATIVE_APP as proof the app has no web view