studio
2023.4
false
- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- The Diagnostic Tool
- Variables
- Arguments
- Imported Namespaces
- Trigger-based Attended Automation
- Recording
- UI Elements
- Control Flow
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Automating Citrix Technologies
- RDP Automation
- Salesforce Automation
- SAP Automation
- VMware Horizon Automation
- Logging
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- About the WebDriver Protocol
- Configuration Steps
- Known Issues and Limitations
- Test Suite - Studio
- Extensions
- Troubleshooting
- About troubleshooting
- Microsoft App-V support and limitations
- Internet Explorer X64 troubleshooting
- Microsoft Office issues
- Identifying UI elements in PDF with Accessibility options
- Repairing Active Accessibility support
- Automating Applications Running Under a Different Windows User
- Validation of large Windows-legacy projects takes longer than expected
Studio User Guide
Last updated Nov 4, 2024
Known Issues and Limitations
When you build your browser automation projects via the WebDriver protocol you need to take into consideration the following:
- Selectors for UI elements inside iframes are not validated. It is recommended to avoid iframes when you build your automation project. This occurs when element identification is done via the browser extension and selector validation via the WebDriver protocol.
- A browser automation created with the WebDriver protocol always creates a new browser session. This means that saved cookies or saved browser data are not taken into consideration when you build your automation project.
- If a selector is not found for a browser with multiple tabs opened, the execution constantly switches between them. In this scenario it is recommended to create your automation project on a single browser tab. This effect is only noticeable during visual browser automation.
- Headless automation does not rely on visual elements. As such, the WebDriver protocol doesn't actually open a visible browser window when it is used in Headless mode. Because of this, Headless automation cannot function with some activities which use hardware events (such as Click or Type Into) in their default state. They must be configured to use the SimulateClick, SimulateType, or SimulateHover properties, or the Send Window Messages property.
- Activities which interact with images (such as Click Image or Find Image) are not supported because they rely on the browser window itself.
- Events monitoring (such as Click Trigger or Hotkey Trigger) is not supported, because they rely on hardware events.
- Using
<WND>tags in the Close Application activity only closes the browser session and not the corresponding webdriver process. It is recommended to use<HTML>tags instead. - When using Chrome or Firefox, the browser window opened via the WebDriver protocol always opens in the same visual space and with the same size specifications. Moreover, some websites have adaptive page layout and this can lead to invalid selectors when the window size is changed. In this regard, it is recommended to use the default browser window size when you create your automation project.
