Selenium adapter captures no DOM on an Appium mobile-web session

[vishnuv688]

What happens

On an Appium mobile-web session (Chrome on Android), the Selenium adapter captures no DOM at all. The trace archive carries no trace.mutations, so the player's replay pane renders blank for every action and the live dashboard shows an empty device frame. Commands, console and assertions are captured normally, so the run looks healthy — only the page is missing.

The other three adapters capture DOM on the same session, so this is not a mobile-web limitation.

Measured

Same emulator, same page, same chromedriver, same run of each adapter's mobile example with DEVTOOLS_MOBILE=web, pointed at a static page served from the host:

adapter	trace.mutations	trace.network
WebdriverIO	present — 3 entries, 3 DOM anchors, 2 frame snapshots	0 bytes
Nightwatch	present — 699,695 bytes	0 bytes
Python	present — 234,023 bytes	0 bytes
Selenium	absent — no such file	0 bytes

Environment: Appium 3.7.0, uiautomator2 7.6.1, emulator sdk_gphone64_arm64 Android 16 (API 36), Chrome 133.0.6943.137 on device, chromedriver 133.0.6943.141, selenium-webdriver 4.46.0.

Why

Appium's BiDi surface has no script module, so script.addPreloadScript cannot register and document-start injection is unavailable. Every adapter falls back to per-document <script> injection here — Nightwatch logs BiDi preload unavailable … WebDriver instance must support BiDi protocol, Selenium logs the same thing as Cannot read properties of undefined (reading 'script'). So the failing preload is not the distinguishing factor.

What differs is how quickly each adapter's fallback becomes usable. Selenium's collector was ready after the run had finished:

11:30:07.875  test 1 starts                                    (no collector)
11:30:09.523  test 1 ends                                      (no "collector ready" line at all)
11:30:11.043  Collector missing on the current document, re-injecting
11:30:11.052  test 2 ends
11:30:11.516  ✓ Script injected and collector ready            <- 464 ms after the last test

Nothing was ever drained, so no mutation stream was written. Nightwatch's injection and drain go over the raw WebDriver transport from the navigation hook and land inside the test; Selenium's re-injection is triggered by a "collector missing" detection on a later command and then waits on a readiness poll plus settle. On desktop Chrome the preload makes that path moot, which is why this only shows up against Appium.

Test length is not the cause: the Nightwatch and WebdriverIO web branches issue the same two commands and still capture.

Secondary: network is empty on mobile web for every adapter

trace.network is 0 bytes in all four runs. Appium serves no BiDi network events, and the Chrome perf-log fallback needs goog:loggingPrefs: { performance: 'ALL' }, which no mobile config sets. Worth deciding separately whether mobile web should request the capability or state the gap.

Reproducing

Needs an Android emulator, Appium with the uiautomator2 driver, and a chromedriver matching the device's Chrome (Appium's autodownload frequently has no matching build; pass the path via appium:chromedriverExecutable on the server, or CHROMEDRIVER_EXECUTABLE for the WebdriverIO example, which is the only one that reads it).

Serve any static page on the host, then run each adapter's mobile example in web mode against it and compare the archives. The mobile examples used here are the ones in #389.

Suggested direction

Not started, and the choice is open:

• make Selenium's fallback injection eager on navigation rather than reactive to a later "collector missing" detection, so it matches Nightwatch's behaviour; or
• have Selenium skip the BiDi attach for a session that advertises Appium, taking the fallback path deliberately from the start, the way the WebdriverIO mobile config does with wdio:enforceWebDriverClassic.

The first is the real fix; the second is a narrower workaround that also removes the failed-preload warning and the jwproxy performance-capture error that the same sessions log.