Many mobile apps are hybrid: native shells with embedded web content rendered in a WebView. The Mobile Recorder handles both worlds in the same session. It detects WebView regions automatically and lets you capture their elements either as native mobile elements or as web elements, whichever identifies them more reliably.
Automatic Detection
No configuration is needed. With the recorder ON, hovering over a WebView area shows a "Web Region" badge on the tooltip, signaling web-rendered content.
Native Mode and Web Mode
Within a WebView, you choose how elements are seen:
- Native Mode (default). Elements are identified by their native mobile properties (for example, "android.widget.TextView"). The tooltip shows "MobileElement", the native class, and a red indicator: "Native Mode: Press Alt+ C for Web Elements."
- Web Mode. Elements are identified by their web properties (for example, "button#login-btn"). The tooltip shows "WebElement", the web selector, and a blue indicator: "Web Mode: Press Alt+ C for Native Elements."
Switch between modes with Option + C (macOS) or Alt + C (Windows). The switch can take a few seconds; wait for the indicator to update before interacting.
Which Mode, When
Default to Native Mode. It keeps execution faster and avoids depending on WebView debugging flags that may not be present in every environment. It works well when the web content is simple and adequately represented in the native tree with reliable accessibility attributes.
Switch to Web Mode when you need finer-grained control (CSS selectors, form fields, nested web components), when the native representation is too coarse or unreliable, or when you cannot hover cleanly on the element's bounds in native mode.
Moving Between Pages and Back to Native
The recorder follows the WebView automatically: as the embedded web content navigates from page to page, Web Mode stays with the visible page, and when you leave the WebView for native screens, the recorder returns to native identification on its own. There is nothing to manage.
How WebView Elements Are Stored
Storage depends on the mode and, in Web Mode, on the web locator strategy set in Project Preferences:
| Capture Mode | Locator Strategy | Stored As | In Repository? |
|---|---|---|---|
| Native Mode (in WebView) | Smart Locator or XPath | MobileElement | Yes, with native attributes |
| Web Mode (in WebView) | Smart Locator | WebElement, applicable to Desktop/Tablet | Yes, with web selector attributes |
| Web Mode (in WebView) | Locator-Free | Embedded in the statement | No; the label lives in the command text |
Note on cross-platform portability: Web Mode elements are ordinary web elements, shared as-is wherever the same web content appears; they do not carry per-OS (iOS/Android) Element Instances. If an element inside a WebView differs between iOS and Android and needs platform instances, capture it in Native Mode so it lands in the repository as a mobile element. See Cross-Platform Portability: iOS and Android.
When WebView Content Is Not Detected
If your app is hybrid but no "Web Region" badge appears where you expect one, check three things:
-
WebView debugging is enabled in the app. The development team must enable it (on Android,
setWebContentsDebuggingEnabled(true); the equivalent on iOS). Without it, the automation framework cannot inspect the WebView's content. - iOS: Safari Remote Automation is on. On the device, enable Settings > Safari > Advanced > Remote Automation.
- The app was launched by ACCELQ. Select the app from the Application dropdown in the device selection dialog rather than tapping its icon on the device. ACCELQ must manage the app session to enable WebView inspection.
Comments
0 comments
Please sign in to leave a comment.