XWIKI-23126: NavigationPanelAdministrationIT#navigationPanelAdministration is flickering

[surli]

Jira URL

https://jira.xwiki.org/browse/XWIKI-23126

Changes

Description

• Fix a DOM-read race in NavigationPanelAdministrationPage (page object used by NavigationPanelAdministrationIT) that caused the test to intermittently read the navigation tree mid-mutation or before it had finished (re)loading.

Clarifications

Investigated via Develocity (community.develocity.cloud): over the last 30 days the test failed in ~4.2% of its 718 runs (30 failures + 1 flaky), spread across master and stable-16.10.x, multiple browsers/DBs/CI agents — ruling out CI infra as the cause. The failures fell into a few related assertion-mismatch signatures around getNavigationTree().getTopLevelPages() flip-flopping between the real page list, [], and the "No pages found" placeholder, plus one NoSuchElementException in isPinned().

Root cause, confirmed by reading the client-side JS (PanelsCode/NavigationConfigurationSheet.xml) and the page objects:

• exclude()/include() perform a Selenium drag-and-drop that triggers purely client-side, synchronous jQuery/jsTree DOM mutations (show_node/hide_node/create_node + the "No pages found" placeholder toggle) — there's no server round-trip. But NavigationPanelAdministrationPage returned immediately after the drag-and-drop call, before that mutation was necessarily reflected in the DOM, so a caller reading the tree right after could observe a mix of pre- and post-mutation state.
• getPageByTitle() (used by isPinned/pinPage/unpinPage/dragBefore) searched the tree without first waiting for it to be ready, which raced with the tree's initial AJAX load right after a page reload (saveAndReload()), producing the observed NoSuchElementException.
• getNavigationTree()'s existing waitForIt() doesn't help here: it only waits for .jstree-container-ul to exist and aria-busy != "true", and aria-busy is only toggled during the tree's initial load — it becomes a permanent no-op for every later mutation.

This is a reopened manifestation of the previously "fixed" XWIKI-21606 — that earlier fix (March 2025) was incomplete, since it didn't add real synchronization after exclude/include/pin/dragBefore.

Fix: exclude()/include() now wait (waitUntilTopLevelPagesState) until the dragged pages have actually become hidden/visible in the tree before returning, and getPageByTitle() now waits for the tree to finish (re)loading (getNavigationTree()) before searching it.

Out of scope: a separate, distinct test-isolation issue was also observed in the Develocity data (extra top-level pages leaking in from sibling nested tests in the same AllIT suite) — unrelated to this DOM-timing race, not fixed here.

Screenshots & Video

N/A (test-only change, no product UI change).

Executed Tests

• mvn clean verify -pl .../xwiki-platform-panels-test-pageobjects -Plegacy — compiles cleanly, 0 Checkstyle violations.
• Validated the fix by temporarily replacing @Test with @RepeatedTest(value = N, failureThreshold = 1) on navigationPanelAdministration and running it against a real Docker/Firefox instance:
  • mvn clean install -pl .../xwiki-platform-panels-test-docker -Plegacy,integration-tests,docker -Dit.test=AllIT$NestedNavigationPanelAdministrationIT#navigationPanelAdministration -Dxwiki.test.ui.browser=firefox
  • 10/10 passed, then 50/50 passed — 60 consecutive runs, 0 failures — versus the ~4% failure rate observed in CI over the last month.
  • The temporary @RepeatedTest change was reverted before this PR; only the actual page-object fix is included.

Expected merging strategy

• Prefers squash: Yes
• Backport on branches: none

🤖 Generated with Claude Code

[github-actions]

💚 All backports created successfully

Status	Branch	Result
✅	stable-17.10.x
✅	stable-18.4.x

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details