Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#391 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
android, typescript
Domínio
devtools, mobile-dev, testing-qa

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
10
Forks
2
Merge médio
1d 9h
PRs com merge (30d)
21

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de webdriverio/devtools

Todas as issues de webdriverio/devtools

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.