After XWIKI-25071 was merged (2026-10-06), the test still failed in 4 of 46 runs. The 3 failures on branches containing the fix were all on Firefox; Chrome was green in 10/10 runs. They have two causes.
1. Concurrent uploads into a new page: product bug, XWIKI-22643
The test deletes the page first, so both users upload into a page that doesn't exist yet. Both upload requests load the page as new, and the second save is refused: error 9001 "already exists but the document to be saved is marked as new" on MariaDB (17.10.x #312, 18.4.x #146), a primary key violation on HSQLDB. That upload is lost, which also moves the following text (the assertEquals failure on 18.4.x). Forcing the race locally (a delay between loading and saving in the upload handler) made the test fail 3/3 with the CI symptom.
Fix: https://github.com/xwiki/xwiki-platform/pull/6687. The save now detects the concurrent save and the upload handler retries it. With the forced race, all attachments are kept, on HSQLDB, MySQL, MariaDB, PostgreSQL and Oracle.
2. Waiting for an inactive tab: test bug
The test ends in the second tab and waits there (waitForUploadsToFinish, 10s) for the uploads of the first tab, which the browser then throttles because it is inactive. Measured locally with timestamps in both tabs and on the server, while the first tab was inactive:
its queued second upload was sent 1.6–3s after the first one ended;
its realtime changes reached the other tab 1–2s late, 2–3s when the tab was busy, against about 60ms in the other direction.
With a slower upload, as on CI, the wait took 8.2–11.8s against the 10s timeout. Without any delay, everything finishes within about a second locally, before the throttling matters. This explains master #9002: the PNG upload of the first tab still showed as a placeholder at the timeout, without any error.
RealtimeRichTextAreaElement already has repeatedWait, which reactivates the other tabs between short waits, but only the text and content waits used it. Fix: https://github.com/xwiki/xwiki-platform/pull/6686 makes waitForUploadsToFinish use it too. The same forced setups then took 4.7–7.3s, and the test passes unforced on Firefox and Chrome. The PR also logs the status of each upload in the realtime debug dump, so that a future failure shows whether an upload failed, was aborted or was still running.
Local runs don't reproduce CI's timing, so CI will be the final confirmation.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
