Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#391 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, typescript
Área
devtools, mobile-dev, testing-qa

Línea de trabajo

Start at the Selenium adapter’s navigation hook and collector-missing re-injection path, then compare it with the Nightwatch mobile example referenced in #389. Reproduce with the Android emulator and Appium setup, checking whether collection begins before the test ends. Done means the Selenium archive contains trace.mutations and the replay pane and device frame show the page; trace.network is a separate concern.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
2
Merge medio
1 d 9 h
PR fusionados (30 d)
21

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de webdriverio/devtools

Todos los issues de webdriverio/devtools

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.