MOSIP-44311: Fix and optimize ARC UI automation failures

[damodarguru]

MOSIP-44311: Fix and optimize ARC UI automation failures

Summary by CodeRabbit

• Tests

  • Improved stability with retry loops for authentication, supervisor approval and uploads; added post-flow logout verification across languages.
  • Improved camera-permission handling before photo capture; strengthened MockSBI settings interactions.

• Bug Fixes

  • Reduced intermittent failures in uploads, biometric flows and verification by adding resilient retry logic.

• Refactor

  • Enhanced base UI helpers and updated language-specific locators for more reliable element detection.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added retry-based UI flows and locator/utility enhancements across Android UI tests: locator-based BasePage helpers, camera-permission handling, MockSBI settings interaction, PendingApproval API changes across languages, Camera/Operator biometric changes, and multiple test-class renames and retry loops for authentication and upload steps.

Changes

Cohort / File(s)	Summary
Core retry-enabled test cases ui-test/src/main/java/regclient/androidTestCases/* (e.g., BiometricCorrection.java, NewRegistration*.java, PreRegFetchingPacket.java, UpdateMyUin*.java, LostUin.java, Settings.java, LoginTest.java)	Introduced 3-try retry loops for navigation/authentication and upload actions; removed some single-step assertions; added MockSBI settings clicks and language-aware logout flows; renamed login test class and adjusted related TestNG config.
Base utilities (locator-based API) ui-test/src/main/java/regclient/page/BasePage.java	Added locator-based helpers: isElementDisplayed(By), click(By), isElementEnabled(By), hideKeyboardAndClick(By), scrollUntilVisible(By,int), clickAndsendKeysToTextBoxByLocator(By,String), and wait helpers; improved scrolling and keyboard safety.
Camera & MockSBI pages ui-test/src/main/java/regclient/page/CameraPage.java, .../MockSBIPage.java	Camera: added isRetakeButtonDisplayed(), hardened click loops for image/OK interactions. MockSBI: added deviceConfigTitle and clickOnMockSbiSettingsButton() with retry+verify.
Document upload: camera permission ui-test/src/main/java/regclient/pages/*/DocumentUploadPage*.java (Arabic/English/French/Hindi)	Inserted cameraPage.handleCameraPermission() calls after CameraPage instantiation in multiple upload flows to ensure permissions before camera interactions.
PendingApproval API changes (all locales) ui-test/src/main/java/regclient/pages/*/PendingApproval*.java (english, french, hindi, kannada, tamil, arabic)	Removed isSubmitButtonEnabledWithEmptyUsername() and clickOnPendingApprovalSubmitButton(int) variants; added isSubmitButtonDisabledWithEmptyUsername() to check disabled state; updated some accessibility locators in Arabic.
UpdateOperatorBiometrics changes ui-test/src/main/java/regclient/page/UpdateOperatorBiometricspage.java, .../UpdateOperatorBiometricspage*.java	Removed updateBiometricsAndWaitPopup() abstract/method implementations across locales; simplified validateThreshold(...) implementations to direct lookup+parse.
Locale-specific locator and small behavior changes ui-test/src/main/java/regclient/pages/*/*.java (Arabic/French/English/Hindi/etc.)	Multiple locator string updates for Arabic pages, By-based locators in Arabic login, reduced wait times in DemographicDetailsEnglish, added backButton fields in ManageApplications pages, and small retry additions in SupervisorBiometricVerification French.
Test runner / config ui-test/src/main/java/regclient/utils/TestRunner.java, ui-test/testng.xml	Renamed TestNG class reference from logintest to LoginTest and updated XML accordingly.

Sequence Diagram(s)

sequenceDiagram
    actor TestCase as Test Case
    participant PageObj as Page Object
    participant Driver as WebDriver
    participant Device as Device UI

    Note over TestCase,Device: Retry-enabled navigation/upload flow
    TestCase->>PageObj: trigger action (e.g., clickContinue)
    loop up to 3 attempts
        PageObj->>Driver: click(locator)
        Driver->>Device: tap
        Device-->>Driver: response
        PageObj->>Driver: isElementDisplayed(authLocator)?
        Driver->>Device: query UI
        alt element found
            Device-->>Driver: found
            Driver-->>PageObj: true
            PageObj-->>TestCase: success (break)
        else not found
            Device-->>Driver: not found
            Driver-->>PageObj: false
            PageObj-->>TestCase: retry
        end
    end
    TestCase->>TestCase: assert based on retry result

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Possibly related PRs

• MOSIP-42652: ARC UI automation #620 — Overlapping changes touching MockSBIPage and test flows (MockSBI settings usage in BiometricCorrection/Settings).
• MOSIP-43667:ARC UI automation add testcases and move to develop branch #640 — Related updates to page objects and retry patterns (BasePage, PendingApproval, MockSBI interactions).

Suggested reviewers

• jayesh12234
• ase-101
• mohanachandran-s

Poem

🐰 Hops of code in loops of three,

I tap, I wait, then tap with glee,
From camera light to auth once more,
I chase the UI, explore the door,
Tests sing strong — a rabbit's chore.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.66% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main objective of the PR—fixing and optimizing ARC UI automation failures—and directly relates to the substantial changes across multiple test files and page objects that introduce retry logic, fix flaky tests, and improve reliability.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 14

🤖 Fix all issues with AI agents

In `@ui-test/src/main/java/regclient/androidTestCases/BiometricCorrection.java`:
- Around line 1509-1513: Before proceeding to the correction flow (right before
the assertTrue(registrationTasksPage.isOperationalTaskDisplayed()) check) reset
the biometric configuration set earlier by clearing the introducer-biometric
flags on FetchUiSpec and restoring individual biometric mode; specifically call
the routine or set the properties on FetchUiSpec (e.g., clear any "introducer"
flags or call FetchUiSpec.resetToIndividualBiometrics / resetBiometricConfig if
available) so the correction flow will require individual captures rather than
skipping them.

In `@ui-test/src/main/java/regclient/androidTestCases/NewRegistrationAdult.java`:
- Around line 597-605: The retry loop around
manageApplicationsPage.clickOnUploadButton() currently breaks out if
isNoNetworkFoundDisplayed() becomes false but doesn't fail the test if all
retries still show "No Network Found"; update both occurrences (the block at the
shown lines and the similar block at 1323-1330) to, after the loop, check
manageApplicationsPage.isNoNetworkFoundDisplayed() and explicitly fail the test
(throw an assertion or call the test framework's fail method) if it still
returns true so the test cannot falsely pass when uploads never succeed.

In
`@ui-test/src/main/java/regclient/androidTestCases/NewRegistrationAdultException.java`:
- Around line 612-618: The retry loop around
manageApplicationsPage.clickOnUploadButton() may exit with "No Network Found"
still displayed; after the loop (the for loop that checks
manageApplicationsPage.isNoNetworkFoundDisplayed()), add a failing assertion or
explicit test failure that verifies the upload did not end with the "No Network
Found" state (e.g.,
assertFalse(manageApplicationsPage.isNoNetworkFoundDisplayed()) or throw an
assertion/error) so the test fails if the condition persists after retries.

In `@ui-test/src/main/java/regclient/androidTestCases/NewRegistrationInfant.java`:
- Around line 551-557: The retry loop calling
manageApplicationsPage.clickOnUploadButton() and checking
manageApplicationsPage.isNoNetworkFoundDisplayed() must assert failure if, after
the retries, the "No Network Found" message is still displayed; update the code
to perform the three attempts, then after the loop check
isNoNetworkFoundDisplayed() and call the test-failure mechanism (e.g.,
Assert.fail or the project's test helper) with a clear message so the test stops
instead of continuing when upload never started.

In `@ui-test/src/main/java/regclient/androidTestCases/NewRegistrationMinor.java`:
- Around line 595-601: The retry loop in NewRegistrationMinor that calls
manageApplicationsPage.clickOnUploadButton() up to three times never fails the
test if all attempts still show the "No Network Found" message; update the code
to track success (e.g., a boolean like uploadSucceeded) inside the loop by
checking manageApplicationsPage.isNoNetworkFoundDisplayed() after each click,
break on success, and after the loop add an explicit assertion or fail the test
if uploadSucceeded is false (or if isNoNetworkFoundDisplayed() is still true) so
the test fails when all retries fail.

In
`@ui-test/src/main/java/regclient/androidTestCases/NewRegistrationMinorException.java`:
- Around line 711-717: The retry loop around
manageApplicationsPage.clickOnUploadButton() can mask a persistent failure;
after attempting up to 3 times, check
manageApplicationsPage.isNoNetworkFoundDisplayed() and explicitly fail the test
(e.g., throw an AssertionError or call the test framework's fail) if it still
returns true so the test does not continue silently; keep the existing loop and
break logic but add a post-loop assertion referencing
isNoNetworkFoundDisplayed() to enforce failure when the "No Network Found" state
persists.

In `@ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinInfant.java`:
- Around line 541-548: The retry loop around
manageApplicationsPage.clickOnUploadButton() doesn't assert success; modify it
to track whether an upload succeeded by introducing a boolean (e.g.,
uploadSucceeded) that is set true when isNoNetworkFoundDisplayed() returns false
(or when a success indicator is observed), break the loop when true, and after
the loop add an assertion (or throw) if uploadSucceeded is still false so the
test fails when "No Network" persists; reference
manageApplicationsPage.clickOnUploadButton(),
manageApplicationsPage.isNoNetworkFoundDisplayed(), and the surrounding retry
loop to locate where to add the flag and final assertion.

In `@ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinMinor.java`:
- Around line 676-682: The retry loop calling
manageApplicationsPage.clickOnUploadButton() and checking
manageApplicationsPage.isNoNetworkFoundDisplayed() may exit while the UI still
shows "No Network Found", allowing the test to pass incorrectly; after the loop
in UpdateMyUinMinor, add an assertion (e.g., assertFalse or fail) that verifies
manageApplicationsPage.isNoNetworkFoundDisplayed() is false and fail the test if
it remains true so the test explicitly fails when upload never starts. Ensure
you reference the existing methods clickOnUploadButton() and
isNoNetworkFoundDisplayed() when adding the post-retry check.

In
`@ui-test/src/main/java/regclient/androidTestCases/UpdateMyUINUpdateDemographicDetails.java`:
- Around line 535-541: The retry loop calling
manageApplicationsPage.clickOnUploadButton() currently breaks on success but
does not fail if all 3 attempts still show the network error; add a post-loop
assertion using manageApplicationsPage.isNoNetworkFoundDisplayed() (or the test
framework's fail/assertFalse) to explicitly fail the test when the upload never
succeeded after 3 tries, and include a clear message like "Upload failed: No
network found after 3 attempts" to surface the error; keep the retry count and
existing calls to clickOnUploadButton() and isNoNetworkFoundDisplayed()
unchanged.

In
`@ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinUpdateDocuments.java`:
- Around line 536-542: After retrying upload up to three times, add an assertion
that verifies the upload actually succeeded instead of silently continuing when
manageApplicationsPage.isNoNetworkFoundDisplayed() remains true; after the for
loop in UpdateMyUinUpdateDocuments, call a success-checking method (or assert
that a success indicator is visible/that isNoNetworkFoundDisplayed() is false)
and fail the test if the upload did not succeed so persistent network errors
produce a test failure rather than a false green.

In `@ui-test/src/main/java/regclient/page/BasePage.java`:
- Around line 124-132: The isElementDisabled method currently swallows all
exceptions and returns true, causing false positives; update isElementDisabled
in BasePage to not mask missing/uncheckable elements by catching only expected
exceptions (e.g., NoSuchElementException, TimeoutException) and returning false
for those cases (or rethrowing unexpected exceptions), and ensure you call
waitForElementToBeVisible and then check element.isEnabled() and the "clickable"
attribute as before so missing elements do not make tests pass incorrectly.

In `@ui-test/src/main/java/regclient/page/CameraPage.java`:
- Around line 78-83: The isCoordinatesDisplayed method currently ignores inputs
and always returns true; replace the no-op with a real bounds check in
isCoordinatesDisplayed(int x, int y) by obtaining the viewport or target element
bounds (e.g., via driver.manage().window().getSize() or
targetElement.getLocation()/getSize()) and return (x,y) inside those bounds,
removing the meaningless try/catch that swallows errors; if relying on an
element, use its getLocation/getSize to compute left/right/top/bottom and return
true only when x and y are within those limits, otherwise return false.

In `@ui-test/src/main/java/regclient/page/PendingApproval.java`:
- Line 53: Remove the legacy method isSubmitButtonEnabledWithEmptyUsername()
from the subclasses PendingApprovalHindi and PendingApprovalFrench (the old
implementations at PendingApprovalHindi:149 and PendingApprovalFrench:195) since
all subclasses now implement the new abstract
isSubmitButtonDisabledWithEmptyUsername(); delete those method definitions and
any direct calls or references to isSubmitButtonEnabledWithEmptyUsername() in
those classes, and run a quick search to ensure no remaining references or
unused imports remain after removal.

In
`@ui-test/src/main/java/regclient/pages/english/SupervisorBiometricVerificationpageEnglish.java`:
- Around line 360-374: In clickOnVerifyAndSaveButton
(SupervisorBiometricVerificationpageEnglish) add a short pause after each
clickOnElement(verifyAndSaveButton) before checking isDismissPageLoaded so
retries don't fire immediately; implement a small wait (e.g., a brief
Thread.sleep or an explicit wait/polling that checks for the dismiss page or a
DOM condition) between the click and the next iteration to allow the UI to
render, keeping the existing 3-attempt loop and logging behavior intact.

♻️ Duplicate comments (1)

ui-test/src/main/java/regclient/androidTestCases/PreRegFetchingPacket.java (1)

1016-1023: Same retry pattern issues apply here.

The retry loops in minorPreRegFetching and infantPreRegFetching have the same concerns as noted for adultPreRegFetching - consider adding delays and extracting to a common helper method.

Also applies to: 1518-1525

🧹 Nitpick comments (13)

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinInfant.java (1)

429-437: Add a short wait/backoff between retries.

These retries click and check immediately, which can still be flaky if the UI needs time to render. Consider a brief wait (or explicit wait helper) between attempts. Apply the same pattern to the supervisor-auth loop below as well.

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUINUpdateDemographicDetails.java (1)

405-415: Consider adding a brief delay between retry attempts.

The retry loop clicks continue without any wait between iterations. If the UI hasn't stabilized, rapid clicking may cause unexpected behavior. Adding a small delay (e.g., Thread.sleep(500) or a page-object wait method) between attempts would improve reliability.

Also, consider extracting the magic number 3 to a named constant (e.g., MAX_RETRIES) for consistency across all retry loops in the test suite.

♻️ Suggested improvement

 boolean isAuthenticationPageDisplayed = false;
 for (int i = 0; i < 3; i++) {
     previewPage.clickOnContinueButton();
-
+    Thread.sleep(500); // Allow UI to stabilize
     if (authenticationPage.isAuthenticationPageDisplayed()) {
         isAuthenticationPageDisplayed = true;
         break;
     }
 }
 assertTrue(isAuthenticationPageDisplayed, "Authentication page not displayed after retries");

ui-test/src/main/java/regclient/pages/arabic/OperationalTaskPageArabic.java (1)

21-25: descriptionContains() is appropriate for localized content testing; consider verifying resourceId availability only if stability issues arise.

descriptionContains(...) with specific text matching is a standard approach for testing localized UI elements. The Arabic text strings ("تحميل التطبيق", "ما زال يحتاج بتصدير") are specific enough to avoid unintended matches. If you encounter test flakiness with these locators, combine with resourceId() or className() if those attributes are available and stable on the target app. Otherwise, the current selectors are adequate.

ui-test/src/main/java/regclient/pages/french/ManageApplicationsPageFrench.java (1)

87-88: Prefer a stable back-button locator or add a fallback.
android.widget.Button + instance(0) is brittle if button order changes; consider a more specific locator (accessibility id/resource-id) and/or fallback to system back when the element isn’t visible.

♻️ Suggested resilient fallback

 public void clickOnBackButton() {
-    clickOnElement(backButton);
+    if (isElementDisplayed(backButton)) {
+        clickOnElement(backButton);
+    } else {
+        driver.navigate().back();
+    }
 }

Also applies to: 235-236

ui-test/src/main/java/regclient/pages/english/ManageApplicationsPageEnglish.java (1)

90-91: Prefer a stable back-button locator or add a fallback.
android.widget.Button + instance(0) is brittle if button order changes; consider a more specific locator (accessibility id/resource-id) and/or fallback to system back when the element isn’t visible.

♻️ Suggested resilient fallback

 public void clickOnBackButton() {
-    clickOnElement(backButton);
+    if (isElementDisplayed(backButton)) {
+        clickOnElement(backButton);
+    } else {
+        driver.navigate().back();
+    }
 }

Also applies to: 238-239

ui-test/src/main/java/regclient/pages/french/SupervisorBiometricVerificationpageFrench.java (1)

354-368: Add a brief wait between retries to avoid rapid double-clicks.
A short delay after a failed attempt gives the UI time to transition and reduces flakiness.

♻️ Suggested backoff

 for (int i = 0; i < 3; i++) {
     clickOnElement(verifyAndSaveButton);

     if (isDismissPageLoaded()) {
         isDismissLoaded = true;
         break;
     }
+    waitTime(1);
 }

ui-test/src/main/java/regclient/pages/hindi/PendingApprovalHindi.java (1)

234-236: Consider consolidating the empty-username submit helpers.

Line 234-236 adds the disabled-state helper, but isSubmitButtonEnabledWithEmptyUsername remains (Line 149-151). To avoid confusion, consider removing/deprecating the old helper and standardizing on one semantic.

ui-test/src/main/java/regclient/page/MockSBIPage.java (1)

48-49: Prefer a stable locator for Device Config.
Text-based XPath is brittle if the label changes or is localized. If MockSBI exposes a resource-id or content-desc for this title, prefer that (or add a fallback).

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinUpdateBiometrics.java (1)

429-440: Consider a short backoff (or helper) between retries.
A small wait between attempts can reduce rapid re-clicks and give the UI time to settle; extracting a shared retry helper would also cut duplication.

Also applies to: 513-523, 552-558

ui-test/src/main/java/regclient/androidTestCases/PreRegFetchingPacket.java (4)

448-455: Consider adding a delay between retry attempts.

The retry loop clicks the continue button rapidly without waiting for the UI to respond. This could cause race conditions where the click is registered but the page hasn't transitioned yet, leading to immediate re-clicks.

Adding a short delay (e.g., 500ms-1s) between retries would allow the UI to settle and improve reliability.

♻️ Suggested improvement

 for (int i = 0; i < 3; i++) {
     previewPage.clickOnContinueButton();
+    Thread.sleep(1000); // Allow UI to transition

     if (authenticationPage.isAuthenticationPageDisplayed()) {
         isAuthenticationPageDisplayed = true;
         break;
     }
 }

---

535-542: Extract common retry logic into a reusable helper method.

This retry pattern (click action → check condition → break on success) is duplicated across all three test methods for both authentication pages and upload operations. Consider extracting it to a utility method in BasePage or a test helper class.

♻️ Example helper method

// In BasePage or a test utility class
public static boolean retryUntilCondition(Runnable action, Supplier<Boolean> condition, int maxRetries, long delayMs) throws InterruptedException {
    for (int i = 0; i < maxRetries; i++) {
        action.run();
        Thread.sleep(delayMs);
        if (condition.get()) {
            return true;
        }
    }
    return false;
}

Usage:

boolean isDisplayed = BasePage.retryUntilCondition(
    () -> pendingApproval.clickOnAuthenticateButton(),
    () -> pendingApproval.isSupervisorAuthenticationTitleDisplayed(),
    3, 1000
);
assertTrue(isDisplayed, "Supervisor Authentication page not displayed after retries");

---

573-579: Network retry should include adequate delay for the operation to complete.

The upload operation likely involves network I/O which takes longer than UI transitions. Without a delay, the loop may click upload repeatedly before the previous attempt has a chance to complete or the network error state is updated.

Consider adding a longer delay (e.g., 2-3 seconds) to allow the upload operation to attempt completion.

♻️ Suggested improvement

 for (int i = 0; i < 3; i++) {
     manageApplicationsPage.clickOnUploadButton();
+    Thread.sleep(3000); // Allow time for upload attempt

     if (!manageApplicationsPage.isNoNetworkFoundDisplayed()) {
         break;
     }
 }

---

426-426: Unused variable Aid.

The Aid variable is assigned but never used in any of the three test methods. If it's intended for verification (as suggested by the commented-out validatePreRegAndApplicationIdMatch call), consider completing that implementation. Otherwise, remove the unused variable.

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In `@ui-test/src/main/java/regclient/androidTestCases/logintest.java`:
- Line 73: The public class declaration "public class LoginTest" in the file
named "logintest.java" violates Java's requirement that a public class name
matches its filename; rename the source file from logintest.java to
LoginTest.java (or alternatively rename the class to match the existing
filename) so the class LoginTest and the file name are identical and case‑exact.

In `@ui-test/src/main/java/regclient/androidTestCases/PreRegFetchingPacket.java`:
- Around line 1146-1154: The retry loop in PreRegFetchingPacket (using
manageApplicationsPage.selectLatestAidCheckBox(), clickOnUploadButton(), and
isNoNetworkFoundDisplayed()) can exit after 3 failures and produce false
positives; after the for-loop add a post-retry assertion that verifies the
upload did not leave the "No Network Found" state (e.g.,
assertFalse(manageApplicationsPage.isNoNetworkFoundDisplayed()) or
assertTrue(manageApplicationsPage.isUploadSuccessDisplayed()) depending on
available success indicator) before calling
manageApplicationsPage.clickOnBackButton() so the test fails when all retries
still show network error.

In `@ui-test/src/main/java/regclient/page/BasePage.java`:
- Around line 845-856: The catch in BasePage.isElementEnabled(By locator) is
catching the wrong TimeoutException type; replace the Netty TimeoutException
import with org.openqa.selenium.TimeoutException so the catch (TimeoutException
| NoSuchElementException e) will correctly handle WebDriverWait timeouts thrown
by wait.until(...) in isElementEnabled; update the import statement and re-run
tests to ensure Selenium timeouts are caught as intended.

♻️ Duplicate comments (2)

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUINUpdateDemographicDetails.java (1)

535-546: Fix correctly addresses the missing assertion issue.

The upload retry loop now properly tracks success state and asserts after the loop, ensuring the test fails with a clear message if the upload never succeeds. This resolves the concern from the previous review.

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinMinor.java (1)

675-686: Verified: Past review concern addressed.

The retry loop now correctly tracks success via the uploadSuccess flag and includes the post-loop assertion at line 686. This ensures the test explicitly fails when "No Network Found" persists after retries.

,

🧹 Nitpick comments (7)

ui-test/src/main/java/regclient/pages/hindi/PendingApprovalHindi.java (1)

229-232: Align “empty username” intent with actual check.

Right now this only checks the submit button state; if the username field isn’t empty, the result can be misleading. Consider validating the username textbox content (or explicitly documenting the precondition).

♻️ Possible adjustment

 	public boolean isSubmitButtonDisabledWithEmptyUsername() {
-		return isElementDisabled(submitButton);
+		String username = userNameTextBox.getText();
+		return (username == null || username.trim().isEmpty())
+				&& isElementDisabled(submitButton);
 	}

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinUpdateDocuments.java (1)

403-414: Retry pattern looks good; consider adding a small delay between attempts.

The retry mechanism properly handles flaky UI transitions with a success flag and post-loop assertion. However, clicking Continue three times in rapid succession (no delay between iterations) may not give the UI enough time to respond, potentially causing all attempts to fail even when the system would succeed with a brief pause.

💡 Optional: Add a brief delay between retry attempts

 boolean isAuthenticationPageDisplayed = false;

 for (int i = 0; i < 3; i++) {
     previewPage.clickOnContinueButton();

     if (authenticationPage.isAuthenticationPageDisplayed()) {
         isAuthenticationPageDisplayed = true;
         break;
     }
+    Thread.sleep(500); // Allow UI to stabilize before next attempt
 }
 assertTrue(isAuthenticationPageDisplayed, "Authentication page not displayed after retries");

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinMinor.java (1)

547-554: Consider extracting retry logic to a reusable helper.

The same retry pattern (3 iterations, break on success, boolean flag) appears three times in this test. A helper method in BasePage or a test utility class would reduce duplication:

// Example helper signature
protected boolean retryUntilTrue(int maxAttempts, Runnable action, Supplier<Boolean> condition)

This would centralize retry count and make the test more maintainable if retry behavior needs tuning later.

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinInfant.java (2)

426-437: Guard the retry loop to avoid re‑clicking after navigation.

Right now the click happens before any “already navigated” check, so a slow render can trigger an extra click on a missing/incorrect element. Consider checking first (and optionally right after the click) to avoid flakiness.

♻️ Proposed fix

-		for (int i = 0; i < 3; i++) {
-			previewPage.clickOnContinueButton();
-
-			if (authenticationPage.isAuthenticationPageDisplayed()) {
-				isAuthenticationPageDisplayed = true;
-				break;
-			}
-		}
+		for (int i = 0; i < 3; i++) {
+			if (authenticationPage.isAuthenticationPageDisplayed()) {
+				isAuthenticationPageDisplayed = true;
+				break;
+			}
+			previewPage.clickOnContinueButton();
+			if (authenticationPage.isAuthenticationPageDisplayed()) {
+				isAuthenticationPageDisplayed = true;
+				break;
+			}
+		}

---

505-514: Apply the same “already displayed” guard to the supervisor auth retry.

This loop has the same click‑then‑check pattern, which can re‑click after navigation completes and cause intermittent failures.

♻️ Proposed fix

-		for (int i = 0; i < 3; i++) {
-			pendingApproval.clickOnAuthenticateButton();
-
-			if (pendingApproval.isSupervisorAuthenticationTitleDisplayed()) {
-				isPageDisplayed = true;
-				break;
-			}
-		}
+		for (int i = 0; i < 3; i++) {
+			if (pendingApproval.isSupervisorAuthenticationTitleDisplayed()) {
+				isPageDisplayed = true;
+				break;
+			}
+			pendingApproval.clickOnAuthenticateButton();
+			if (pendingApproval.isSupervisorAuthenticationTitleDisplayed()) {
+				isPageDisplayed = true;
+				break;
+			}
+		}

ui-test/src/main/java/regclient/androidTestCases/logintest.java (1)

124-131: Keep a minimal negative-login assertion (optional).
Since the error message is removed, consider still asserting that a wrong password doesn’t navigate away, so the negative path remains covered.

💡 Example tweak

-//      Password incorrect message currently removed from APK
-//		loginPage.clickOnloginButton();
-//		assertTrue(loginPage.isPasswordIncorrectErrorMessageDisplayed(),
-//				"verify if error message should be displayeded as password incorrect!");
+// Password incorrect message currently removed from APK
+		loginPage.clickOnloginButton();
+		assertTrue(loginPage.isPasswordHeaderDisplayed(),
+				"Verify user remains on password step after invalid login");

ui-test/src/main/java/regclient/androidTestCases/UpdateMyUinUpdateBiometrics.java (1)

428-439: Consider adding a small backoff or explicit wait between retry attempts.
Right now the retries click immediately; adding a short wait (or waiting for a page state change) can prevent rapid double-submits and improve stability.

Also applies to: 512-524, 551-563

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@ui-test/src/main/java/regclient/page/BasePage.java`:
- Around line 891-903: In clickAndSendKeysToTextBox replace the unconditional
((HidesKeyboard) driver).hideKeyboard() call with the safe helper
hideKeyboardIfVisible() to avoid exceptions when the keyboard is not present;
locate the method clickAndSendKeysToTextBox and swap the final hideKeyboard
invocation to call the existing hideKeyboardIfVisible() helper instead (do not
change other wait/clear/sendKeys behavior).

♻️ Duplicate comments (1)

ui-test/src/main/java/regclient/page/BasePage.java (1)

21-21: TimeoutException import looks correct.

🧹 Nitpick comments (3)

ui-test/src/main/java/regclient/page/BasePage.java (3)

832-842: Guard clickability before interacting in the wait loop.
wait.until(...) here doesn’t ensure the element is actually clickable; ElementClickInterceptedException / ElementNotInteractableException can still fail fast. Prefer an explicit clickability wait and then interact once.

♻️ Proposed refactor

 public void clickAndsendKeysToTextBoxByLocator(By locator, String value) {
 	WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(20));
 	wait.ignoring(StaleElementReferenceException.class);
-
-	wait.until(Webdriver -> {
-		WebElement element = Webdriver.findElement(locator);
-		element.click();
-		element.clear();
-		element.sendKeys(value);
-		return true;
-	});
+	WebElement element = wait.until(ExpectedConditions.elementToBeClickable(locator));
+	element.click();
+	element.clear();
+	element.sendKeys(value);
 }

---

845-857: Clarify whether this is a wait-for-enabled or a boolean check.
As written, a disabled element will wait the full timeout before returning false. If you only need a snapshot, wait for presence and then check isEnabled() once, or rename to indicate it waits for enablement.

♻️ Optional tweak for snapshot semantics

 public boolean isElementEnabled(By locator) {
 	try {
 		WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(20));
 		wait.ignoring(StaleElementReferenceException.class);
-
-		return wait.until(Webdriver -> {
-			WebElement element = Webdriver.findElement(locator);
-			return element.isEnabled();
-		});
+		WebElement element = wait.until(ExpectedConditions.presenceOfElementLocated(locator));
+		return element.isEnabled();
 	} catch (TimeoutException | NoSuchElementException e) {
 		return false;
 	}
 }

---

879-888: Watch out for compounded waits in scrollUntilVisible.
isElementDisplayed(locator) already waits up to 10s; multiplied by maxScrolls, this can create long stalls. Consider a non-waiting visibility probe inside the loop if you want faster scrolling iterations.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@ui-test/src/main/java/regclient/androidTestCases/LoginTest.java`:
- Around line 436-449: The retry loop currently only checks
supervisorBiometricVerificationpage.isDismissPageLoaded() and may re-click
supervisorBiometricVerificationpage.clickOnVerifyAndSaveButton() even if a
success popup has appeared; update the loop to, after each click, check both
supervisorBiometricVerificationpage.isDismissPageLoaded() and a success-popup
check (e.g., supervisorBiometricVerificationpage.isSuccessPopupLoaded() — add
that helper if it doesn't exist), short‑circuit and break when either is true,
and add a short backoff between attempts using the existing wait utility to
reduce flakiness.

🧹 Nitpick comments (1)

ui-test/src/main/java/regclient/androidTestCases/LoginTest.java (1)

124-131: Remove or gate the stale commented-out assertion block.

The password-incorrect check is fully commented (Lines 127–131). If the APK no longer supports this message, delete the block to avoid drift; if it’s temporary, consider gating it behind a config flag instead of leaving dead comments.

♻️ Proposed cleanup (remove stale block)

-//      Password incorrect message currently removed from APK
-//		loginPage.clickOnloginButton();
-//		assertTrue(loginPage.isPasswordIncorrectErrorMessageDisplayed(),
-//				"verify if error message should be displayeded as password incorrect!");

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In
`@ui-test/src/main/java/regclient/pages/hindi/UpdateOperatorBiometricspageHindi.java`:
- Around line 402-409: The locator in validateThreshold uses an English
descriptionContains("Threshold") which will fail in Hindi; update the
MobileBy.AndroidUIAutomator call inside validateThreshold to search for the
Hindi label ("सीमा") instead of "Threshold" (i.e., change the
descriptionContains argument used in the
driver.findElement/MobileBy.AndroidUIAutomator expression) so the element lookup
and subsequent content-desc extraction work in the Hindi locale.

In
`@ui-test/src/main/java/regclient/pages/kannada/UpdateOperatorBiometricspageKannada.java`:
- Around line 402-410: The UiScrollable lookup in validateThreshold uses
descriptionContains("Threshold") which is English and will fail for Kannada;
update the locator in validateThreshold (the MobileBy.AndroidUIAutomator call
that assigns el) to use the Kannada content-desc (e.g.,
descriptionContains("ಸೀಮಾಂಕ")) or, better, switch to a locale-agnostic locator
such as the element's resource-id or accessibility id if available so the
findElement call reliably locates the threshold element across locales.

🧹 Nitpick comments (1)

ui-test/src/main/java/regclient/androidTestCases/LoginTest.java (1)

679-693: Avoid re-clicks when the success popup appears during the wait.

The loop checks immediately after click, then sleeps. If the popup appears during the wait, the next iteration can still click again. Consider re-checking after the wait before re-clicking.

♻️ Proposed tweak to re-check after the wait

-		for (int i = 1; i <= 5; i++) {
-			UpdateOperatorBiometricspage.clickOnVerifyAndSaveButton();
-
-			if (UpdateOperatorBiometricspage.isOperatorBiometricsUpdatedPopupLoaded()) {
-				updateBiometricsAndWaitPopup = true;
-				break; // success
-			}
-
-			BasePage.waitTime(10);
-		}
+		for (int i = 1; i <= 5; i++) {
+			UpdateOperatorBiometricspage.clickOnVerifyAndSaveButton();
+
+			if (UpdateOperatorBiometricspage.isOperatorBiometricsUpdatedPopupLoaded()) {
+				updateBiometricsAndWaitPopup = true;
+				break; // success
+			}
+
+			BasePage.waitTime(10);
+			if (UpdateOperatorBiometricspage.isOperatorBiometricsUpdatedPopupLoaded()) {
+				updateBiometricsAndWaitPopup = true;
+				break; // success after wait
+			}
+		}