Repository navigation
bug: the visual service fails on Android Chrome through Appium 3 in the default WebDriver BiDi session (workaround: wdio:enforceWebDriverClassic) #1232
Description
Environment (please complete the following information):
- Node.js version: 24.20.0
- NPM version: 11.19.0
- Browser name and version: Chrome 133.0.6943.137 on an Android 16 emulator (Pixel 9 Pro, API 36)
- Platform name and version: macOS 27; Appium 3.8.0, UiAutomator2 driver 8.7.0 (appium-android-driver 14.2.0), Chromedriver 133.0.6943.141
- WebdriverIO version: 9.32.0 (also 10.0.0-alpha.163)
@wdio/visual-serviceversion: 10.1.0 (also thewdio0-v10-compliancebranch of feat: support WebdriverIO v10 (keep v9) and fix the visual matchers with Jasmine #1213)
Config of WebdriverIO + @wdio/visual-service
capabilities.js
// MODE=bidi (default), classic or forward
const mode = process.env.MODE ?? 'bidi'
export const capabilities = {
platformName: 'Android',
browserName: 'Chrome',
'appium:automationName': 'UiAutomator2',
'appium:deviceName': process.env.DEVICE ?? 'emulator-5554',
'appium:newCommandTimeout': 240,
'appium:chromeOptions': { args: ['--no-first-run', '--disable-fre'] },
...(mode === 'classic' ? { 'wdio:enforceWebDriverClassic': true } : {}),
...(mode === 'forward' ? { 'appium:chromedriverForwardBiDi': true } : {}),
}
// The Android emulator reaches the host at 10.0.2.2
export const pageUrl = 'http://10.0.2.2:8765/mobile.html'
export { mode }wdio.conf.js
import { capabilities, mode } from './capabilities.js'
export const config = {
runner: 'local',
hostname: '127.0.0.1',
port: 4723,
specs: ['./test/visual.spec.js'],
capabilities: [capabilities],
framework: 'mocha',
reporters: ['spec'],
services: [['visual', {
baselineFolder: `./.tmp/${mode}/baseline`,
screenshotPath: `./.tmp/${mode}/actual`,
}]],
logLevel: 'warn',
connectionRetryCount: 0,
mochaOpts: { timeout: 240000 },
}Describe the bug
On Android Chrome through Appium 3, the visual service does not work in the default session. WebdriverIO opens a WebDriver BiDi session (browser.isBidi is true), but Appium does not support the browser BiDi commands in this session:
browser.url()fails:WebDriver Bidi command "browsingContext.navigate" failed with error: unknown method - Method has not yet been implemented- every
browser.execute()fails:WebDriver Bidi command "script.callFunction" failed with error: unknown command
The visual service runs all its client-side scripts with browser.execute(), so all the visual commands and matchers fail. With WebdriverIO 9 and the published 10.1.0, the service before hook fails (Error getting mobile screen size), the matchers are not added, and the user only sees expect(...).toMatchScreenSnapshot is not a function.
This is not a bug in the service code. The workaround is 'wdio:enforceWebDriverClassic': true in the capabilities: then all the tests pass. This repository uses it in its Android web configs since #417, but the README does not tell users.
WebdriverIO v10 requires Appium 3, so all the users who upgrade will get this problem on Android Chrome.
To Reproduce
A small repro: a WebdriverIO-only script (probe.mjs, no service) and a visual test (test/visual.spec.js). Steps:
- Start an Android emulator with Chrome (
emulator-5554). npm i -g appium@3,appium driver install uiautomator2, thenappium --port 4723 --allow-insecure "uiautomator2:chromedriver_autodownload".npm install, thennpm run page(serveswww/on port 8765; the emulator openshttp://10.0.2.2:8765/mobile.html).MODE=bidi npm run probe,MODE=bidi npm test, and the same withMODE=classicandMODE=forward. RunMODE=classic npm testtwo times: the first run saves the baselines.
package.json
{
"name": "wdio-appium3-android-bidi-repro",
"private": true,
"type": "module",
"scripts": {
"page": "python3 -m http.server 8765 --bind 127.0.0.1 --directory www",
"test": "wdio run wdio.conf.js",
"probe": "node probe.mjs"
},
"devDependencies": {
"@wdio/cli": "^9.32.0",
"@wdio/globals": "^9.31.3",
"@wdio/local-runner": "^9.32.0",
"@wdio/mocha-framework": "^9.32.0",
"@wdio/spec-reporter": "^9.32.0",
"@wdio/visual-service": "^10.1.0",
"webdriverio": "^9.32.0"
}
}probe.mjs
// No visual service, no test runner: shows the WebdriverIO + Appium result only.
// Usage: MODE=bidi|classic|forward node probe.mjs
import { remote } from 'webdriverio'
import { capabilities, mode, pageUrl } from './capabilities.js'
const browser = await remote({ hostname: '127.0.0.1', port: 4723, logLevel: 'error', capabilities })
const run = async (name, fn) => {
try {
console.log(`${name}: OK ${JSON.stringify(await fn())?.slice(0, 60) ?? ''}`)
} catch (err) {
console.log(`${name}: ERROR ${err.message.split('\n')[0].slice(0, 150)}`)
}
}
try {
console.log(`mode ${mode}, isBidi: ${browser.isBidi}`)
await run('url()', async () => { await browser.url(pageUrl) })
await run('getUrl()', () => browser.getUrl())
await run('execute(() => document.title)', () => browser.execute(() => document.title))
await run('executeScript("return document.title", [])', () => browser.executeScript('return document.title', []))
} finally {
await browser.deleteSession()
}test/visual.spec.js
import { browser, $, expect } from '@wdio/globals'
import { pageUrl } from '../capabilities.js'
describe('Android Chrome through Appium 3', () => {
it('opens the page', async () => {
console.log(`isBidi: ${browser.isBidi}`)
await browser.url(pageUrl)
await expect($('h1')).toHaveText('Visual test')
})
it('matches the screen', async () => {
await expect(browser).toMatchScreenSnapshot('screen')
})
it('matches an element', async () => {
await expect($('#target')).toMatchElementSnapshot('target')
})
})www/mobile.html
<!doctype html>
<html>
<head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Mobile</title>
<style>
body { margin: 0; background: #fff; font-family: sans-serif; }
h1 { margin: 16px; font-size: 24px; color: #1b5e20; }
#target { margin: 16px; width: 200px; height: 100px; background: #388e3c; border: 4px solid #1b5e20; }
</style>
</head>
<body><h1>Visual test</h1><div id="target"></div></body>
</html>Results (the same with WebdriverIO 9.32.0 and 10.0.0-alpha.163):
probe.mjs |
bidi (default) |
classic |
forward (appium:chromedriverForwardBiDi) |
|---|---|---|---|
isBidi |
true |
false |
true |
url() |
error: browsingContext.navigate … unknown method |
OK | error (same) |
execute(() => document.title) |
error: script.callFunction … unknown command |
"Mobile" |
error (same) |
executeScript('return document.title', []) |
OK | OK | OK |
npm test (visual service) |
3 of 3 fail | 3 of 3 pass | 3 of 3 fail |
Expected behavior
The visual service works on Android Chrome through Appium 3 in the default WebdriverIO session, or the docs tell users to use 'wdio:enforceWebDriverClassic': true, and the service gives a clear error.
Log
WebdriverIO 9.32.0 with the published 10.1.0, MODE=bidi:
WARN webdriverio:ShadowRootManager: Could not register shadow root preload script, shadow DOM will not be pierced in this session: WebDriver Bidi command "script.addPreloadScript" failed with error: unknown command
WARN @wdio/visual-service:@wdio/image-comparison-core:utils: Error getting mobile screen size:
Error: WebDriver Bidi command "script.callFunction" failed with error: unknown command - The requested resource could not be found, or a request was received using an HTTP method that is not supported by the mapped resource.
ERROR @wdio/utils:shim: Error: WebDriver Bidi command "script.callFunction" failed with error: unknown command - ...
1) Android Chrome through Appium 3 opens the page
WebDriver Bidi command "browsingContext.navigate" failed with error: unknown method - Method has not yet been implemented
2) Android Chrome through Appium 3 matches the screen
TypeError: expect(...).toMatchScreenSnapshot is not a function
3) Android Chrome through Appium 3 matches an element
TypeError: expect(...).toMatchElementSnapshot is not a function
Additional context
What I found about the cause (local tests on the emulator):
- WebdriverIO adds
webSocketUrl: trueto every session that has abrowserName, except Safari and'wdio:enforceWebDriverClassic': true(packages/webdriver/src/utils.ts). There is no exception for Appium. - Since Appium 2.5.0, the Appium server sends back its own BiDi URL when the client asks for one. UiAutomator2 does not forward the BiDi commands to Chromedriver by default, so
browsingContext.navigateandscript.callFunctionare not supported. An Appium maintainer said the same in No connection to WebDriver Bidi was established webdriverio#14600. - With Appium 2.19.0 (UiAutomator2 4.2.9),
execute()also fails in this BiDi session, buturl()works: WebdriverIO uses the ClassicnavigateTo()whenbrowsingContext.navigatefails withunknown error(url.ts). Appium 3 sendsunknown method, so this fallback does not apply. Thus the visual service already fails with Appium 2.5+ in BiDi; Appium 3 also breaksurl(). - The option
'appium:chromedriverForwardBiDi': truemust forward BiDi to Chromedriver, but it has no effect in a browser session:startChromeSession()does not give the context name tosetupNewChromedriver(), socacheChromedriverCaps()returns before it saves the Chromedriver BiDi URL. (The webview path, line 292, gives it.) Chromedriver did return awebSocketUrl. - With that line patched locally, Appium forwards BiDi to Chromedriver and
url()works, butexecute()fails withno such frame - Context CHROMIUM not found: on mobile, the WebdriverIO context manager uses the Appium context name fromgetContext()as the current context (context.ts), and BiDi uses it as the browsing context ID. Afterbrowser.switchToWindow(await browser.getWindowHandle()),execute()works, and the visual service passes like in Classic. In this real BiDi session,execute('mobile: deviceInfo')fails withReferenceError: deviceInfo is not defined, andexecuteScript('mobile: deviceInfo', [])works (this confirms the change of fix: run Appiummobile:commands with executeScript #1220).
iOS Safari through Appium 3 (XCUITest) is not affected: WebdriverIO does not ask for BiDi for Safari.
Proposed work in this repository:
- README: for Android Chrome through Appium, set
'wdio:enforceWebDriverClassic': true(WebdriverIO v9 and v10). - When the matchers or the instance data cannot be set up because of this, give a clear warning with the workaround, not
toMatchScreenSnapshot is not a function.
The root causes are in WebdriverIO (points 1, 3, 5) and in appium-android-driver (point 4). Issues there are not opened yet.
Follow-up
The default BiDi session works only when all of the fixes below are done. A partial fix does not help: for example, with only the Appium fix, url() works but every execute() still fails.
This repository (closes this issue)
- README: for Android Chrome through Appium, set
'wdio:enforceWebDriverClassic': true(WebdriverIO v9 and v10). - A clear warning with this workaround when the service cannot set up in an Android BiDi session (not
toMatchScreenSnapshot is not a function).
appium/appium-android-driver (issue or PR to open)
-
startChromeSession()must give the context name tosetupNewChromedriver(), so thatappium:chromedriverForwardBiDiworks in a browser session (point 4). - Question: can the BiDi forward be the default for browser sessions?
webdriverio/webdriverio (issue to open)
- Mobile web BiDi: use the window handle, not the Appium context name (
CHROMIUM), as the browsing context ID (point 5). This bug is independent of Appium. - For Android Chrome through Appium: add
appium:chromedriverForwardBiDi: truewhen WebdriverIO asks for BiDi (after the Appium fix is released), or do not ask for BiDi (point 1). Keep BiDi when the user setswebSocketUrl: true, and do not change appium-geckodriver and appium-chromium-driver, because they support BiDi. - Optional: in
url(), also use the Classic fallback for the Appium 3 errorunknown method(point 3). - v10 migration guide, Appium section: Android Chrome needs
'wdio:enforceWebDriverClassic': trueuntil these fixes are released.
When the upstream fixes are released, we can test the default session again with the repro of this issue, and then update the README.
Activity
plum117 commentedon Oct 4, 2026
New results on
main(after #1220)I ran the repro again on
main(commit972150b): WebdriverIO v10, Appium 3.8.0, UiAutomator2, Android emulator (emulator-5554).isBidiurl()toMatchScreenSnapshot/toMatchElementSnapshottruebrowsingContext.navigate…unknown methodscript.callFunction…unknown command'wdio:enforceWebDriverClassic': truefalseWhat changed since the published 10.1.0
getMobileScreenSize()sentmobile: deviceInfowithexecute(). In BiDi, this call failed, and the fallbackexecute()also failed. Thus the servicebeforehook stopped before it added the matchers, and the user sawexpect(...).toMatchScreenSnapshot is not a function.mobile:commands with executeScript #1220 sends themobile:commands withexecuteScript(). Onmain, the servicebeforehook passes in BiDi: there is noError getting mobile screen sizewarning, and the matchers are added. The erroris not a functiondoes not occur onmain.check*command and matcher fails at the firstexecute()inbeforeScreenshot, with the Appium errorWebDriver Bidi command "script.callFunction" failed with error: unknown command. This error does not tell the user about the workaround.Updated proposal for this repository
'wdio:enforceWebDriverClassic': truefor Android Chrome through Appium (WebdriverIO v9 and v10).beforehook, for an Android web session in BiDi only, send one test callbrowser.execute(() => true). If it fails, log one clear warning with the workaround. A test call is better than a check of the capabilities: the warning stops by itself when the WebdriverIO and Appium fixes are released.The item "not
toMatchScreenSnapshot is not a function" in the follow-up list now applies only to 10.1.0. Onmain, the symptom is thescript.callFunctionerror.fix: close the gaps of the WebdriverIO v10 audit (emulation, matchers…
feat: support WebdriverIO v10 (keep v9) and fix the visual matchers w…
plum117 commentedon Oct 9, 2026
The 2 follow-ups from my comment above are open:
'wdio:enforceWebDriverClassic': true. Checked again with Appium 3.8.0 and UiAutomator2 8.7.0: in BiDi,browser.url()now already fails (browsingContext.navigate…unknown method); in Classic, the visual checks pass.feat: warn when an Android browser session in BiDi cannot run scripts
docs: tell Android Chrome users to use WebDriver Classic with Appium (#…
feat: warn when an Android browser session in BiDi cannot run scripts (…
plum117 commentedon Oct 18, 2026
Status 2026-10-18:
mainon 2026-10-10, but not in 10.0.2 (latest) or 10.1.0-alpha.30 (next).appium-android-driver>= 14.2.4 (the fix of [uiautomator2] 'appium:chromedriverForwardBiDi' has no effect in a Chrome browser session appium/appium#22940): 8.7.0 (latest) still pins 14.2.0.9.0.0-beta.1usesappium-android-driver15.0.0-beta.1 (not tested yet).master, 3.8.0 is still the latest.url('http://…')fails withbrowsingContext.navigate … unknown method, andexecute()withscript.callFunction … unknown command.wdio:enforceWebDriverClassic: truestill works.When the releases are out: re-test with
appium:chromedriverForwardBiDi: true, then decide whether to keep the warning of #1314 and close this issue.plum117 commentedon Oct 18, 2026
Status 2026-10-18 (later): 1 of the 3 releases is out.
appium-android-driver14.2.0; the fix of [uiautomator2] 'appium:chromedriverForwardBiDi' has no effect in a Chrome browser session appium/appium#22940 needs >= 14.2.4.'wdio:enforceWebDriverClassic': truestays the workaround until the 2 Appium releases are out.