[dprevost-LMI]

Description

Fixes #1238.

In a multiremote session, checkElement, saveElement and toMatchElementSnapshot failed. This PR fixes the causes and adds tests that find each cause. It also:

• changes the dev dependencies from WebdriverIO 10.0.0-alpha.150 to the 10.0.0 release, and the published ranges from ^10.0.0-0 to ^10.0.0
• runs the OCR e2e tests on https://v9.webdriver.io, because the new v10 website removed the page that they use

This is not a v10 regression: the bug was already in v9 (see below).

The causes and the fixes

Call	Error before	Cause	Fix
expect(multiRemoteBrowser.$('#el')).toMatchElementSnapshot('tag')	The visual service did not add the "checkElement" command to this session	A multiremote element has no parent, so getBrowserObject() did not find a browser.	toMatchElementSnapshot compares the element of each instance (element.getInstance(name)) with the browser of that instance, and gives the result of each instance, as toMatchScreenSnapshot does.
multiRemoteBrowser.getInstance('chrome').checkElement(element, 'tag'), and toMatchElementSnapshot on the element of an instance	no such node	The multiremote addCommand() of WebdriverIO v9 and v10 also adds the command to each instance. The service added the multiremote element commands last, so they replaced the commands of each instance. #997 fixed this order for the page commands only.	The service adds the multiremote element commands before the commands of each instance, as it does for the page commands.
multiRemoteBrowser.checkElement(await multiRemoteBrowser.$('#el'), 'tag')	Unsupported type: function	The multiremote command gave the multiremote element to the command of each instance.	The multiremote command gives the element of each instance (element.getInstance(browserName)).
multiRemoteBrowser.checkElement(multiRemoteBrowser.$('#el'), 'tag') (not awaited, found in the review)	Unsupported type: function	On an element that is not awaited, a property is a chained command, so isMultiRemote is a function, not true.	The multiremote command awaits the element before it reads the multiremote fields.

Other changes:

• isMultiRemoteElement(): a new type guard for the multiremote elements of v9 (isMultiremote) and v10 (isMultiRemote).
• The types of multiRemoteBrowser.checkElement() and multiRemoteBrowser.saveElement() accept a multiremote element. Before, the example of the issue failed the type check.
• The compareResult() parameter type accepts the result of each instance. This removes an as unknown as cast.

Not a v10 regression

The three calls of the issue, on WebdriverIO 9.29.1 (standalone multiremote, two headless Chrome sessions):

Call	@wdio/visual-service@10.1.0 (before the v10 work)	This PR
toMatchElementSnapshot on a multiremote element	browser.checkElement is not a function	pass
getInstance('one').checkElement(element of one)	no such node	pass
multiRemoteBrowser.checkElement(multiremote element)	Unsupported type: function	pass
multiRemoteBrowser.checkElement(multiremote element), not awaited	-	pass

The multiremote element commands come from #423 (July 2024). In v10, only the error text of the first call changed.

Why the tests did not find it

• The unit test mock of the multiremote addCommand() was a plain vi.fn(). It did not add the command to each instance, so the order problem could not show. The mock now does this, as WebdriverIO does.
• No unit test used a multiremote element.
• The multiremote e2e spec tested only saveScreen. It had no element command and no matcher. Its config had autoSaveBaseline: false, so a check command would fail in CI, which has no baselines.

WebdriverIO 10.0.0

• Root dev dependencies: ^10.0.0-0 → ^10.0.0, so the lockfile cannot keep an alpha version. The webdriverio dev dependency of image-comparison-core changes in the same way.
• The @wdio/globals, @wdio/logger and @wdio/types ranges of @wdio/visual-service, @wdio/ocr-service and @wdio/image-comparison-core change from ^9.29.1 || ^10.0.0-0 to ^9.29.1 || ^10.0.0. WebdriverIO v9 (9.29.1 and later) is still supported.
• expect-webdriverio stays on ^8.0.0-0. WebdriverIO 10.0.0 uses 8.0.0-alpha.3, and there is no 8.0.0 release yet.
• In the lockfile, only the WebdriverIO packages change (and pnpm deduplicated ansi-regex and strip-ansi). It has no alpha version of WebdriverIO now. The 10.0.0-0 ranges left in it are peer ranges of the WebdriverIO packages.

OCR e2e tests on the v9 website

The OCR job failed in the beforeEach hook, and it fails in the same way on every PR: element (".hero__title") still not displayed after 15000ms (run).

The code of this PR does not cause it, because the hook fails before the service runs. The OCR spec uses the live home page of https://webdriver.io/, and the v10 website revamp (webdriverio/webdriverio#15700) removed this page (.hero__title, .hero__subtitle, .buttons_pzbO). The new site was deployed on 2026-10-05, with the WebdriverIO 10.0.0 release:

• The OCR job passed at 01:01 UTC (run 37249757843) and failed at 16:39 UTC.
• The archived copy of webdriver.io on 2026-09-29 has .hero__title. The live page does not.
• https://v9.webdriver.io/ still has the old page.

The OCR spec now uses https://v9.webdriver.io for the page and for the two URL checks. Next step (separate PR): move the OCR tests to a static page on guinea-pig.webdriver.io, as webdriverio/guinea-pig#14 did for the webdriverio e2e tests.

Tests

• Unit tests (v9 and v10 shapes):
  • service: a command on one instance runs on that instance only (element and page commands), the multiremote element command gives each instance its own element, also when the element is not awaited
  • matcher: a multiremote element gives the result of each instance, the failure message, and a clear error when the command is missing
  • utils: isMultiRemoteElement()
• E2E, in CI (test.local.desktop.multi): 5 new tests in tests/specs/multiremote.spec.ts. The config now has autoSaveBaseline: true.
  • On the old code, the new tests fail with the errors of the table above. With the fix, they pass.

Local runs on WebdriverIO 10.0.0:

• pnpm test (lint, types, 1084 unit tests): pass
• test.local.chrome.v10, test.local.chrome.v10.jasmine, test.local.desktop.multi (7 tests), test.local.chrome.v10.emulation: pass
• test.ocr.local.desktop (local only): 7 passing (before: all fail in the beforeEach hook)
• test.local.desktop (local only): one failure, the alwaysSaveActualImage: false does not respect browser.checkElement/Screen/FullPageScreen #1115 test, because of stale local baselines. This failure is not related to this PR.
• test.local.multi.web.app (local only): not run, because no Appium and no Android 14 emulator were available. Its spec uses no element command.

Changesets

• .changeset/fix-multiremote-element-commands.md: @wdio/visual-service patch
• .changeset/webdriverio-10-release-ranges.md: patch for @wdio/visual-service, @wdio/ocr-service and @wdio/image-comparison-core

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 4de63a1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@wdio/visual-service	Patch
@wdio/ocr-service	Patch
@wdio/image-comparison-core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[greptile-apps]

Confidence Score: 5/5

[High risk] Updates WebdriverIO to v10 and fixes multiremote element commands.

The PR appears safe to merge; the previous unawaited-element coverage gap is addressed.

Summary

The PR fixes multiremote element commands and matching, moves development dependencies to WebdriverIO 10.0.0, and updates related tests.

• The follow-up change awaits unawaited elements before selecting an element for each browser instance.
• Unit and end-to-end tests now cover that call.
• The OCR tests use the v9 website’s home page.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A["checkElement(multiremote element)"] --> B["Await element"]
  B --> C["Choose each instance's element"]
  C --> D["Run each instance's command"]
  D --> E["Return results by instance"]

Loading

_{Reviews (2) · Last reviewed commit: "fix: await the element of the multiremot..."}