RecycleBinIT#restore is flickering

Reopening rather than filing a duplicate — thanks to the CI check for spotting it.

The previous change raised the Live Data ready timeout, which addressed the failure at openAttachmentsDocExtraPane(). What remains is a different failure, one step further down at page.delete().clickYes(), and it has a concrete cause.

Root cause

AttachmentsPane#setFileToUpload() only sets the file input value: the upload is asynchronous and the method returns immediately. The test then went straight on to open the "More actions" menu to delete the page. But when the upload completes, attachments.js reacts to xwiki:html5upload:done:

$(document).on('xwiki:html5upload:done', function() {
  $("#docAttachments").data('liveData').updateEntries().then(() => {
    updateCount($("#docAttachments").data('liveData').data.data.count);
  });
});
// ... and updateCount() ends in updateAttachmentsNumber():
var tmAttachments = $('#tmAttachments');
tmAttachments[0].normalize();
tmAttachments.contents().last()[0].nodeValue = label;

In menus_content.vm, tmAttachments and tmActionDelete are siblings inside the same tmMoreActions dropdown. So the upload-completion handler rewrites the very menu the test is clicking through. The click on the Delete entry can be lost, the browser then stays on the view page, and clickYes() finds no confirmation button and fails with NoSuchElementException after 10 seconds — exactly what the CI reports.

Note that waitForUploadToFinish() alone would not have been enough: the "Attachment uploaded" notification is shown before xwiki:html5upload:done is fired, and the Live Data refresh that follows is a network round trip. That round trip is the race window, which is why this only bites on a loaded agent and only in one configuration.

RecycleBinIT#restore was the only one of the ~30 setFileToUpload() call sites in the repository that did not wait for the upload at all.

Fix

Wait for the upload notification and for the attachments count to be refreshed before deleting the page. The count is the last thing that chain writes, so waiting for it proves the menu rewrite is over. A new AttachmentsPane#waitForNumberOfAttachments() holds the wait, so any other test that uploads an attachment before using the "More actions" menu can rely on it.

Verification

Run on chrome / mysql latest / tomcat 11-jdk25 — the only configuration in which the test fails on the CI (2 failures out of 12 runs there over the last 28 days, 0 out of 539 in the 30 other configurations):

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0 -- in org.xwiki.flamingo.test.docker.RecycleBinIT
BUILD SUCCESS

A local rate measurement would not be meaningful here: the default configuration has never exhibited the failure, so a "before" run there proves nothing. The CI is what will confirm the rate on the affected configuration.