Skip to main content
Sign in

Resolve Smart Form Authentication failures with Angular Material components

  • Updated

Issue

When configuring the Fusion Web Crawler for Smart Form Authentication on sites using Angular Material components (such as qui-wc-input), the login process fails.

The crawler logs typically show an InvalidElementStateException during the WebDriverSmartFormLogin.findAndSubmit phase.

This occurs because the Smart Form Login targets the outer wrapper components, which do not support standard Selenium operations like .clear().

 

Diagnosis

To confirm this issue, inspect the login page's Document Object Model (DOM).

If the username or password fields are wrapped in custom web components (e.g., <qui-wc-input>) and the actual <input> tags are nested inside these wrappers or within a Shadow DOM, the default Smart Form selector logic will likely fail.

Signs of this issue include:

  • The crawler can "see" the element but cannot interact with it.

  • Error messages specifically mention an failure to execute .clear() on an element.

  • Standard parameters like ::usernameXPath:: or ::passwordXPath:: appear to be ignored or result in state exceptions.

     

Environment

  • Fusion 5.9.4 and earlier.

  • Web Crawler (Self-Hosted).

  • Sites utilizing Angular Material or similar custom web component frameworks.

     

Cause

The primary cause is the incompatibility between Selenium's default interaction methods and the complex DOM structure created by Angular Material.

Smart Form Login attempts to interact with the top-level element identified by the selector.

If that element is a custom component wrapper rather than a native HTML <input>, Selenium cannot perform the necessary text clearing and entry actions.

Additionally, Angular reactive forms may require specific JavaScript events that the standard Smart Form process does not trigger.

 

Resolution

The most reliable resolution for complex SSO or Angular-based login pages is to bypass the automated login form by providing a full session cookie set.

 

Step 1: Obtain Session Cookies

Manually capture the complete set of cookies required for an authenticated session using a tool like Postman or cURL.

Do not rely solely on a single cookie (e.g., pa.ext); ensure the full cookie payload from a valid session is captured.

 

Step 2: Configure Crawler Authentication

  • Navigate to the Web Crawler configuration.

  • Disable JavaScript crawling if it is causing redirects back to the authentication page during the crawl.

  • Use the Cookie field in the crawler configuration to manually provide the captured cookies.

Step 3: Alternative Smart Form Configuration

If cookie-based authentication is not feasible, attempt to target the native input elements directly using explicit XPath selectors in the Smart Form Parameters section.

Add the following properties to the Parameters table:

Plaintext

 
userIdXPath = ;;BY_XPATH;;//input[@id='input-userId']
password = ;;BY_XPATH;;//input[@id='input-password']
::submitButtonXPath:: = //button[@type='submit']
::waitForElementXPath:: = //input[@id='input-userId']
::clickBeforeTypingXPath:: = //input[@id='input-userId']
::sleepBeforeSubmitMs:: = 2000

  • Use the actual ID of the nested <input> element found during DOM inspection.

  • Ensure the ::clickBeforeTypingXPath:: is set to the same native input element to force focus.

  • If the login page uses Shadow DOM, these selectors may still be inaccessible, necessitating the cookie-based approach described in Step 1.

Powered by Zendesk