Skip to content

Releases: webdriverio/visual-testing

[email protected]

13 May 07:11
f207620
Compare
Choose a tag to compare

Patch Changes

  • 5c6c6e2: Fix capturing element screenshots with BiDi

    This release fixes #919 where an element screenshot, that was for example from an overlay, dropdown, popover, tooltip, modal, was returning an incorrect screenshot

    Committers: 1

@wdio/[email protected]

13 May 07:11
f207620
Compare
Choose a tag to compare

Patch Changes

  • 5c6c6e2: Fix capturing element screenshots with BiDi

    This release fixes #919 where an element screenshot, that was for example from an overlay, dropdown, popover, tooltip, modal, was returning an incorrect screenshot

    Committers: 1

  • Updated dependencies [5c6c6e2]

[email protected]

12 May 08:42
b74b398
Compare
Choose a tag to compare

Major Changes

  • bfe6aca: ## 💥 BREAKING CHANGES

    🧪 Web Screenshot Strategy Now Uses BiDi by Default

    What was the problem?

    Screenshots taken via WebDriver's traditional protocol often lacked precision:

    • Emulated devices didn't reflect true resolutions
    • Device Pixel Ratio (DPR) was often lost
    • Images were cropped or downscaled

    What changed?

    All screenshot-related methods now use the WebDriver BiDi protocol by default (if supported by the browser), enabling:

    ✅ Native support for emulated and high-DPR devices
    ✅ Better fidelity in screenshot size and clarity
    ✅ Faster, browser-native screenshots via browsingContext.captureScreenshot

    The following methods now use BiDi:

    • saveScreen / checkScreen
    • saveElement / checkElement
    • saveFullPageScreen / checkFullPageScreen

    What’s the impact?

    ⚠️ Existing baselines may no longer match.
    Because BiDi screenshots are sharper and match device settings more accurately, even a small difference in resolution or DPR can cause mismatches.

    If you rely on existing baseline images, you'll need to regenerate them to avoid false positives.

    Want to keep using the legacy method?

    You can disable BiDi screenshots globally or per test using the enableLegacyScreenshotMethod flag:

    Globally in wdio.conf.ts:

    import { join } from "node:path";
    
    export const config = {
      services: [
        [
          "visual",
          {
            baselineFolder: join(process.cwd(), "./localBaseline/"),
            debug: true,
            formatImageName: "{tag}-{logName}-{width}x{height}",
            screenshotPath: join(process.cwd(), ".tmp/"),
            enableLegacyScreenshotMethod: true, // 👈 fallback to W3C-based screenshots
          },
        ],
      ],
    };

    Or per test:

    it("should compare an element successfully using legacy screenshots", async function () {
      await expect($(".hero__title-logo")).toMatchElementSnapshot(
        "legacyScreenshotLogo",
        { enableLegacyScreenshotMethod: true } // 👈 fallback to W3C-based screenshots
      );
    });

    🐛 Bug Fixes

    • #916: Visual Testing Screenshot Behavior Changed in Emulated Devices

    Committers: 1

@wdio/[email protected]

12 May 08:42
b74b398
Compare
Choose a tag to compare

Major Changes

  • bfe6aca: 💥 BREAKING CHANGES

    🧪 Web Screenshot Strategy Now Uses BiDi by Default

    What was the problem?

    Screenshots taken via WebDriver's traditional protocol often lacked precision:

    • Emulated devices didn't reflect true resolutions
    • Device Pixel Ratio (DPR) was often lost
    • Images were cropped or downscaled

    What changed?

    All screenshot-related methods now use the WebDriver BiDi protocol by default (if supported by the browser), enabling:

    ✅ Native support for emulated and high-DPR devices
    ✅ Better fidelity in screenshot size and clarity
    ✅ Faster, browser-native screenshots via browsingContext.captureScreenshot

    The following methods now use BiDi:

    • saveScreen / checkScreen
    • saveElement / checkElement
    • saveFullPageScreen / checkFullPageScreen

    What’s the impact?

    ⚠️ Existing baselines may no longer match.
    Because BiDi screenshots are sharper and match device settings more accurately, even a small difference in resolution or DPR can cause mismatches.

    If you rely on existing baseline images, you'll need to regenerate them to avoid false positives.

    Want to keep using the legacy method?

    You can disable BiDi screenshots globally or per test using the enableLegacyScreenshotMethod flag:

    Globally in wdio.conf.ts:

    import { join } from "node:path";
    
    export const config = {
      services: [
        [
          "visual",
          {
            baselineFolder: join(process.cwd(), "./localBaseline/"),
            debug: true,
            formatImageName: "{tag}-{logName}-{width}x{height}",
            screenshotPath: join(process.cwd(), ".tmp/"),
            enableLegacyScreenshotMethod: true, // 👈 fallback to W3C-based screenshots
          },
        ],
      ],
    };

    Or per test:

    it("should compare an element successfully using legacy screenshots", async function () {
      await expect($(".hero__title-logo")).toMatchElementSnapshot(
        "legacyScreenshotLogo",
        { enableLegacyScreenshotMethod: true } // 👈 fallback to W3C-based screenshots
      );
    });

    🐛 Bug Fixes

    • #916: Visual Testing Screenshot Behavior Changed in Emulated Devices

    Committers: 1

Patch Changes

[email protected]

18 Apr 05:23
7f78351
Compare
Choose a tag to compare

Major Changes

  • 42956e4: ## 💥 BREAKING CHANGES

    🔍 Viewport Screenshot Logic Reworked for Mobile Web & Hybrid Apps

    What was the problem?

    Screenshots for mobile devices were inconsistent due to platform differences. iOS captures the entire device screen (including status and address bars), while Android (using ChromeDriver) only captures the webview, unless the capability "appium:nativeWebScreenshot": true is used.

    What changed?

    We’ve reimplemented the logic to correctly handle both platforms by default.
    This fix addresses [#747](https://github.com/webdriverio/visual-testing/pull/747).

    💡 Credit to Benjamin Karran (@ebekebe) for pointing us in the right direction to improve this logic!

    What’s the advantage?

    ✅ More accurate full-page and element screenshots on both Android and iOS.
    ⚠️ But this change may break your current baselines, especially on Android and iOS.


    🍏 iOS Element Screenshot Strategy Changed

    What was the problem?

    iOS element screenshots were previously cut from full-device screenshots, which could lead to misalignment or off-by-a-few-pixels issues.

    What changed?

    We now use the element screenshot endpoint directly.

    What’s the advantage?

    ✅ More accurate iOS element screenshots.
    ⚠️ But again, this may affect your existing baselines.


    🖥️ New Full-Page Screenshot Strategy for Desktop Web

    What was the problem?

    The "previous" scroll-and-stitch method simulated user interaction by scrolling the page, waiting, taking a screenshot, and repeating until the entire page was captured.
    This works well for lazy-loaded content, but it is slow and unstable on other pages.

    What changed?

    We now use WebDriver BiDi’s [[browsingContext.captureScreenshot](https://webdriver.io/docs/api/webdriverBidi#browsingcontextcapturescreenshot)] to capture full-page screenshots in one go. This is the new default strategy for desktop web browsers.

    📌 Mobile platforms (iOS/Android) still use the scroll-and-stitch approach for now.

    What’s the advantage?

    ✅ Execution time reduced by 50%+
    ✅ Logic is greatly simplified
    ✅ More consistent and stable results on static or non-lazy pages
    📸 Example

    Still want the old scroll-and-stitch behavior or need fullpage screenshots for pages who have lazy-loading?

    Use the userBasedFullPageScreenshot option to simulate user-like scrolling. This remains the better choice for pages with lazy-loading:

    // wdio.conf.ts
    services: [
      [
        "visual",
        {
          userBasedFullPageScreenshot: true,
        },
      ],
    ];

    Or per test:

    await expect(browser).toMatchFullPageSnapshot("homepage", {
      userBasedFullPageScreenshot: true,
    });

    💅 Polish

    ⚠️ Deprecated Root-Level Compare Options

    What was the problem?

    Compare options were allowed at the root level of the service config, making them harder to group or discover.

    What changed?

    You now get a warning if you still use root-level keys. Please move them under the compareOptions property instead.

    Example warning:

    WARN The following root-level compare options are deprecated and should be moved under 'compareOptions':
      - blockOutStatusBar
      - ignoreColors
    In the next major version, these options will be removed from the root level.
    

    📘 See: [compareOptions docs](https://webdriver.io/docs/visual-testing/service-options#compare-options)


    🐛 Bug Fixes


    🔧 Other

    • 🆙 Updated dependencies
    • 🧪 Improved test coverage
    • 📸 Refreshed image baselines

    Committers: 1

@wdio/[email protected]

18 Apr 05:23
7f78351
Compare
Choose a tag to compare

Major Changes

  • 42956e4: ## 💥 BREAKING CHANGES

    🔍 Viewport Screenshot Logic Reworked for Mobile Web & Hybrid Apps

    What was the problem?

    Screenshots for mobile devices were inconsistent due to platform differences. iOS captures the entire device screen (including status and address bars), while Android (using ChromeDriver) only captures the webview, unless the capability "appium:nativeWebScreenshot": true is used.

    What changed?

    We’ve reimplemented the logic to correctly handle both platforms by default.
    This fix addresses [#747](https://github.com/webdriverio/visual-testing/pull/747).

    💡 Credit to Benjamin Karran (@ebekebe) for pointing us in the right direction to improve this logic!

    What’s the advantage?

    ✅ More accurate full-page and element screenshots on both Android and iOS.
    ⚠️ But this change may break your current baselines, especially on Android and iOS.


    🍏 iOS Element Screenshot Strategy Changed

    What was the problem?

    iOS element screenshots were previously cut from full-device screenshots, which could lead to misalignment or off-by-a-few-pixels issues.

    What changed?

    We now use the element screenshot endpoint directly.

    What’s the advantage?

    ✅ More accurate iOS element screenshots.
    ⚠️ But again, this may affect your existing baselines.


    🖥️ New Full-Page Screenshot Strategy for Desktop Web

    What was the problem?

    The "previous" scroll-and-stitch method simulated user interaction by scrolling the page, waiting, taking a screenshot, and repeating until the entire page was captured.
    This works well for lazy-loaded content, but it is slow and unstable on other pages.

    What changed?

    We now use WebDriver BiDi’s [[browsingContext.captureScreenshot](https://webdriver.io/docs/api/webdriverBidi#browsingcontextcapturescreenshot)] to capture full-page screenshots in one go. This is the new default strategy for desktop web browsers.

    📌 Mobile platforms (iOS/Android) still use the scroll-and-stitch approach for now.

    What’s the advantage?

    ✅ Execution time reduced by 50%+
    ✅ Logic is greatly simplified
    ✅ More consistent and stable results on static or non-lazy pages
    📸 Example

    Still want the old scroll-and-stitch behavior or need fullpage screenshots for pages who have lazy-loading?

    Use the userBasedFullPageScreenshot option to simulate user-like scrolling. This remains the better choice for pages with lazy-loading:

    // wdio.conf.ts
    services: [
      [
        "visual",
        {
          userBasedFullPageScreenshot: true,
        },
      ],
    ];

    Or per test:

    await expect(browser).toMatchFullPageSnapshot("homepage", {
      userBasedFullPageScreenshot: true,
    });

    💅 Polish

    ⚠️ Deprecated Root-Level Compare Options

    What was the problem?

    Compare options were allowed at the root level of the service config, making them harder to group or discover.

    What changed?

    You now get a warning if you still use root-level keys. Please move them under the compareOptions property instead.

    Example warning:

    WARN The following root-level compare options are deprecated and should be moved under 'compareOptions':
      - blockOutStatusBar
      - ignoreColors
    In the next major version, these options will be removed from the root level.
    

    📘 See: [compareOptions docs](https://webdriver.io/docs/visual-testing/service-options#compare-options)


    🐛 Bug Fixes


    🔧 Other

    • 🆙 Updated dependencies
    • 🧪 Improved test coverage
    • 📸 Refreshed image baselines

    Committers: 1

Patch Changes

@wdio/[email protected]

18 Apr 05:23
7f78351
Compare
Choose a tag to compare

Patch Changes

@wdio/[email protected]

18 Apr 05:23
7f78351
Compare
Choose a tag to compare

Patch Changes

@wdio/[email protected]

15 Apr 15:00
80f65d2
Compare
Choose a tag to compare

Patch Changes

Committers: 1

[email protected]

31 Mar 16:04
6ff70b1
Compare
Choose a tag to compare

Minor Changes

  • 7f859aa: Add additionalSearchParams to the Storybook Runner API
  • 307fbec: Add getStoriesBaselinePath to Storybook Runner API, enabling custom file paths (e.g. files with a flat hierarchy in the baselines folder)

Committers: 2