Root cause found: it's a race in the test, not a redundant save in Saver / XWikiFormSaveTarget (correcting the earlier automated comment).
The CI recording of the failing run (master build 1396, chrome / mysql latest / tomcat 11-jdk25) shows:
~5.5 s: the first tab types " two", which starts its 5 s auto-save countdown.
~9-11 s: only then is the second tab opened and the in-place editor loaded (slow on MySQL / Tomcat).
~11.5-12 s: the second tab types " three", exactly when the first tab's countdown fires and the save election starts.
~13 s: the first tab saves ("Saved") a snapshot missing some of the second tab's keystrokes, so the second client is rightfully still dirty and saves its own later changes ~5 s later: that's the second version the test reports.
This is why only the slower configuration fails. Fix: load both editors before anyone types, so that the two edits are made about a second apart, well within the save interval.
Local measurements (xwiki-it-repeat, fresh mode, chrome / mysql latest / tomcat 11-jdk25):
Variant
Runs
Passed
Original test
8
8 (a local machine is too fast to hit the race)
Original test + 5 s pause before the second tab types (simulates the slow load seen on CI)
4
0, all with A second client saved the same changes.
Fixed test + the same 5 s delay (where a slow load now lands: before anyone types)
