UiPath Documentation
activities
latest
false
UI Automation activities

Known Issues and Limitations

Behaviors and constraints to keep in mind when automating browsers with Chromium Automation, for both visible and headless modes.

This page lists the known issues and limitations when you automate browsers with Chromium Automation. Some apply to both modes, while others are specific to headless automation.

General

These limitations apply to both Chromium Automation and Chromium Automation Headless:

Chromium-based browsers only

Chromium Automation supports Chrome, Edge, and other Chromium-based browsers. Selecting it for Firefox or Safari returns an error, and there is no automatic fallback to another automation method. For those browsers, use the Browser Extension or the WebDriver protocol.

Dependency on the DeveloperToolsAvailability Policy

This browser automation method can be blocked by the DeveloperToolsAvailability Group Policy. Chromium Automation cannot start the browser when the DeveloperToolsAvailability Group Policy is set to 2 (Disallow usage of the Developer Tools). Use the Browser Extension or the WebDriver protocol in environments where this policy is enforced.

Dedicated Browser Sessions

A new browser session is always created. Chromium Automation opens a new, isolated browser session with its own user-data-dir and cannot attach to a browser already open on the user's desktop. This makes it unsuitable for attended automation, though it is not a limitation for unattended automation.

Default User Data Directory Restriction

Chromium Automation cannot be used with the default user-data-dir. Because the session is isolated, browser extensions, saved passwords, and session cookies from the user's default browser profile are not available. Incognito mode is supported without additional configuration.

Website Compatibility Restrictions

Chromium Automation cannot be used for some public web sites (similar restriction to WebDriver).

Headless Automation via Chromium Automation

These limitations apply to Chromium Automation Headless, where the browser runs without a visible window.

  1. Hardware events are not supported. Operations that rely on hardware events cannot be performed without a visible window. Use the SimulateClick, SimulateType, and SimulateHover input methods on activities such as Click and Type Into instead of the default hardware-event input.

  2. Image-based activities are not supported. Activities that rely on the rendered screen, such as Click Image and Find Image, are not available in headless mode.

  3. Window-dependent operations are not supported. Operations that depend on a visible window or OS-level rendering — such as native drag-and-drop and hardware mouse simulation — are not supported.

  4. Event monitoring is limited. Triggers that rely on hardware events are not supported in headless mode.

  5. Use a consistent browser window size. Because layout can depend on viewport size, use the default browser window size when you build your automation project to keep selectors and element positions consistent.

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated