Details
-
Bug
-
Resolution: Fixed
-
Major
-
16.10.0
-
None
-
Unknown
-
N/A
-
N/A
-
Description
Problem
Administration UI functional tests that save a non-async administration section intermittently fail with a StaleElementReferenceException. This was observed on CI for
AllIT$NestedPresentationIT#showPageAttachmentsTab:
[Jenkins build 113 (stable-18.4.x)|https://ci.xwiki.org/job/XWiki%20Environment%20Tests/job/xwiki-platform/job/stable-18.4.x/113/testReport/junit/org.xwiki.administration.test.ui/AllIT
$NestedPresentationIT/]
org.openqa.selenium.StaleElementReferenceException: stale element reference: stale element not found
at org.xwiki.test.ui.XWikiWebDriver.findElement(XWikiWebDriver.java:716)
at org.xwiki.administration.test.po.PresentationAdministrationSectionPage.getShowAttachments(PresentationAdministrationSectionPage.java:156)
at org.xwiki.administration.test.ui.PresentationIT.showPageAttachmentsTab(PresentationIT.java:114)
Cross-checking with Develocity's test history shows the same failure, at the same line, recurring in isolation (no other unrelated test failing in the same build) across several
independent builds with different Chrome/JDK combinations, which rules out a one-off infrastructure fluke.
Root cause
AdministrationSectionPage#clickSave(boolean) clicks the section's save button. For a non-async administration section (the common case, a full HTML form submission that reloads
the page), the method returns immediately after the click without synchronizing on the resulting page reload — it only waits when wait is true, which is reserved for async
sections (custom success-message flow).
XWikiWebDriver#findElement(By) resolves the element and then calls scrollTo(), which runs a separate executeScript() call to scroll it into view:
public WebElement findElement(By by) { WebElement element = this.wrappedDriver.findElement(by); return this.scrollTo(element); }
If the full-page reload triggered by the save tears down the DOM in the (small) window between those two calls, the element reference goes stale, and the next page object call (e.g.
reading back the saved value) throws.
Fix
Make clickSave(boolean) synchronize on the reload for non-async sections, using the existing XWikiWebDriver#addPageNotYetReloadedMarker() / #waitUntilPageIsReloaded() idiom
(already used by other page objects such as LoginPage, EditPage, RenamePage) instead of relying on WebDriver's own (unreliable, in this case) navigation synchronization.
This fixes the race for every non-async administration section, not just Presentation, since they all share this clickSave() code path.
Verification
Re-ran the whole PresentationIT class against Tomcat 11/jdk25 + PostgreSQL + Chrome (matching the failing CI job) with showPageAttachmentsTab repeated 10 times: 15/15
executions passed, BUILD SUCCESS.