Selenium WebDriver ↔ UI Pagination: Detecting End‑of‑Data Boundary

The Most Robust Termination Indicator

For the least flaky termination condition, UI-based state verification of the \"Next\" control is the most reliable indicator, provided it is implemented as a check for non-interactability rather than a specific attribute. While hash-change detection is prone to false positives (due to timestamps or session IDs in the DOM) and DevTools network-idle events can trigger prematurely during slow API responses, the UI control is the final authority on whether the application believes more data exists.

Comparison of Boundary Signals

Signal	Reliability	Primary Failure Mode
UI Disabled State	High	CSS-only \"disabled\" looks (not actual attributes)
Hash-Change	Low	Dynamic DOM elements (IDs, timestamps)
Network Idle	Medium	Long-polling or heartbeat requests

Recommended Implementation Steps

To minimize flakiness across Selenium 4+, avoid relying on a single attribute like disabled. Instead, use a hybrid check that verifies both the element's presence and its functional state.

1. Wait for Element Stability: Use WebDriverWait to ensure the pagination control is present in the DOM after a navigation action.
2. Verify Interactivity: Check the absence of a \"disabled\" attribute and the absence of common \"disabled\" CSS classes (e.g., .is-disabled, .disabled).
3. Fallback to Presence: If the UI removes the \"Next\" button entirely on the final page, wrap the element search in a try-catch block or use findElements().isEmpty().
4. Final State Confirmation: If the button is still present and appears enabled, perform a click. If the page content does not change (verified by a specific unique identifier like a Page Number label), treat the current page as the boundary.

On Hybrid Approaches and DevTools

Combining UI checks with Selenium 4 DevTools network-idle events can reduce \"stale element\" exceptions by ensuring the DOM has finished updating before the script queries the button state. However, it does not guarantee consistency because network idle does not always correlate with DOM readiness (e.g., client-side JS rendering delays). Use network idle as a pre-condition for the UI check, not as the termination signal itself.

Verification Command

To verify if a button is functionally disabled regardless of the attribute, you can check the isEnabled() method in combination with a CSS class check:

boolean isLastPage = !nextButton.isEnabled() ||
                       nextButton.getAttribute("class").contains("disabled");

Diagnostic Detail Needed: Does the pagination UI use a static URL parameter (e.g., ?page=X) or is it handled entirely via pushState/AJAX without URL changes?