Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#391 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
android, typescript
Bereich
devtools, mobile-dev, testing-qa

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
10
Forks
2
Ø Merge
1 T. 9 Std.
Gemergte PRs (30 T.)
21

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus webdriverio/devtools

Alle Issues in webdriverio/devtools

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.