Findings from the daily CI check (machine-written, from the Develocity history of the last 28 days: 85 failures in 555 executions). No fix was attempted, for the reasons below.
The failures fall into two groups that should be read separately:
F1, 57 of 85, is not this test flickering. It failed in RealtimeWYSIWYGEditPage.gotoPage → RealtimeEditToolbar.waitUntilConnected, never as the only failure of its build (0/57, the whole RealtimeWYSIWYGEditorIT class failed with it), and only on master between 2026-09-04 and 2026-09-14. The failure rate dropped around 2026-09-14: 26.4% before vs 4.3% after (p=3e-12, adjusted).
The residual (F2/F3/F4) is the real flicker: RealtimeRichTextAreaElement.waitUntilContentContains, via repeatedWait (5 × 2s with tab reactivation), gives up while one tab waits for the other tab's drop or text to arrive. It is the only failure in its build every time (13/13 for F2), and it concentrates on Chrome (master / chrome / mysql latest / tomcat 11-jdk25 is the configuration it keeps coming back in). Latest occurrence: https://ci.xwiki.org/job/XWiki%20Environment%20Tests/job/xwiki-platform/job/master/1385 (2026-09-26).
Why no automated fix: the page object already carries the tab-throttling workaround, so its remaining lever is the wait budget, and a timeout change is not something the check proposes. A test-side option that does not touch a timeout would be to call waitUntilLocalChangesArePushed() after each tab's edit/drop, before switching tabs, so the order of the concurrent edits is forced. At a residual rate of a few percent, though, a repeated-run measurement of 20 executions cannot show such a change works, so it is left to whoever picks this issue up.
