Reopening: this is still happening, with the exact same stack trace. Develocity shows 8 occurrences of this signature, the most recent on master build 1359 (commit 047f9282).
What actually happens
The popover does appear. The CI screenshot archived for the failing test shows the "Disabled Lightbox" page with the image toolbar popover (open-lightbox / download / permalink / copy-id) fully rendered, and the VNC recording shows the whole run: the configuration save completes normally (it redirects to a normally-rendered XWiki.Lightbox.LightboxConfiguration), the page is created, the attachment uploaded, the page reloaded, and then the popover shows on hover.
The lightbox client code can only be on that page if the server rendered it with isLightboxEnabled = 1: the UI extension in XWiki/Lightbox/WebHome.xml guards $xwiki.jsx.use(...), the #lightbox-config script and the #imagePopoverContainer template behind #if ($lightboxConfigObj.getValue('isLightboxEnabled').equals(1)), the JSX is use=onDemand, and nothing else requires xwiki-lightbox. So the configuration change the test had just saved was not visible to the renderer.
Why only this test
disabledLightbox is @Order(1), the very first test of the class. In every failing build it is the only test that fails; every later test re-saves the configuration and passes.
Build 1359 timeline: Tomcat up at 02:46:20, the test extensions (including xwiki-platform-image-lightbox-ui, which ships the configuration document) provisioned through the REST install job 02:46:14 to 02:46:35, test started 02:46:56. So the first configuration save of the suite lands about 20s after a XAR install, while background indexing is still reading every freshly installed document.
That points at a stale copy of the configuration document surviving the save in the document cache. The exact mechanism is not proven from the CI artefacts — what is proven is that the configuration change was not in effect.
Fix
Test-side only, no product change:
LightboxPage.isLightboxEnabled() reports whether the page currently in the browser was rendered with the lightbox, via the #lightbox-config script the UI extension only emits when enabled.
enableLightbox() now verifies that the new value is the one renders see — on the page the save action already lands on, so no extra page load — and saves again if it is not, since re-saving is what drops a stale cached copy. It fails with an explicit message after 3 attempts, so a persistent propagation failure still fails the build and names the real problem instead of reporting "the popover appeared".
disabledLightbox asserts that precondition before hovering, so this failure can no longer masquerade as a lightbox defect.
Validated: AllIT 15/15 on Chrome, and disabledLightbox 10/10 on both Chrome and Firefox with @RepeatedTest.
Unrelated second flicker in the same test
3 of the 12 recorded disabledLightbox failures are a different problem: an upload timeout at LightboxPage.attachFile:89 (AttachmentsPane.waitForUploadToFinish), which has nothing to do with the lightbox configuration. Not addressed here.
Vincent Massol on 01/Sep/26 21:22
Reopening: this is still happening, with the exact same stack trace. Develocity shows 8 occurrences of this signature, the most recent on master build 1359 \(commit 047f9282\).
The popover _does_ appear. The CI screenshot archived for the failing test shows the "Disabled Lightbox" page with the image toolbar popover \(open\-lightbox / download / permalink / copy\-id\) fully rendered, and the VNC recording shows the whole run: the configuration save completes normally \(it redirects to a normally\-rendered {{XWiki.Lightbox.LightboxConfiguration}}\), the page is created, the attachment uploaded, the page reloaded, and then the popover shows on hover.
The lightbox client code can only be on that page if the server rendered it with {{isLightboxEnabled = 1}}: the UI extension in {{XWiki/Lightbox/WebHome.xml}} guards {{$xwiki.jsx.use\(...\)}}, the {{#lightbox\-config}} script and the {{#imagePopoverContainer}} template behind {{#if \($lightboxConfigObj.getValue\('isLightboxEnabled'\).equals\(1\)\)}}, the JSX is {{use=onDemand}}, and nothing else requires {{xwiki\-lightbox}}. So the configuration change the test had just saved was not visible to the renderer.
*Why only this test*
* {{disabledLightbox}} is {{@Order\(1\)}}, the very first test of the class. In every failing build it is the _only_ test that fails; every later test re\-saves the configuration and passes. * Build 1359 timeline: Tomcat up at 02:46:20, the test extensions \(including {{xwiki\-platform\-image\-lightbox\-ui}}, which ships the configuration document\) provisioned through the REST install job 02:46:14 to 02:46:35, test started 02:46:56. So the first configuration save of the suite lands about 20s after a XAR install, while background indexing is still reading every freshly installed document.
That points at a stale copy of the configuration document surviving the save in the document cache. The exact mechanism is not proven from the CI artefacts — what is proven is that the configuration change was not in effect.
*Fix*
Test\-side only, no product change:
* {{LightboxPage.isLightboxEnabled\(\)}} reports whether the page currently in the browser was rendered with the lightbox, via the {{#lightbox\-config}} script the UI extension only emits when enabled. * {{enableLightbox\(\)}} now verifies that the new value is the one renders see — on the page the save action already lands on, so no extra page load — and saves again if it is not, since re\-saving is what drops a stale cached copy. It fails with an explicit message after 3 attempts, so a persistent propagation failure still fails the build and names the real problem instead of reporting "the popover appeared". * {{disabledLightbox}} asserts that precondition before hovering, so this failure can no longer masquerade as a lightbox defect.
Validated: {{AllIT}} 15/15 on Chrome, and {{disabledLightbox}} 10/10 on both Chrome and Firefox with {{@RepeatedTest}}.
*Unrelated second flicker in the same test*
3 of the 12 recorded {{disabledLightbox}} failures are a different problem: an upload timeout at {{LightboxPage.attachFile:89}} \({{AttachmentsPane.waitForUploadToFinish}}\), which has nothing to do with the lightbox configuration. Not addressed here.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
