Branch: refs/heads/stable-17.10.x Home: https://github.com/xwiki/xwiki-platform Commit: 862dc211ea1a820c7ec586c2919776ce80ddc56c https://github.com/xwiki/xwiki-platform/commit/862dc211ea1a820c7ec586c291977... Author: Vincent Massol <[email protected]> Date: 2026-04-27 (Mon, 27 Apr 2026) Changed paths: M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-docker/src/test/it/org/xwiki/flamingo/test/docker/EditIT.java Log Message: ----------- [Misc] Try to fix the failing test on CI. Root cause analysis: Firefox 125+ only shows the beforeunload confirmation dialog when navigation is triggered by a synchronous user gesture. The Save & View flow triggers navigation via an async AJAX callback (onSuccess sets window.location), which no longer qualifies as a user gesture. Firefox silently navigates without showing the dialog — so return false and even event.preventDefault() in onbeforeunload both fail to produce a dialog. New strategy: Instead of fighting the browser to show a dialog, we override maybeRedirect on the AjaxSaveAndContinue instance to be a no-op. This way: 1. The AJAX save completes normally 2. The "Saved" notification is displayed (with 30-second timeout) 3. The form is disabled (set by disableEditors() before the AJAX request) 4. Navigation is not triggered — no beforeunload dialog needed 5. Both assertions (waitForNotificationSuccessMessage("Saved") and assertFalse(editWiki.isEnabled())) can be checked cleanly 6. Then setup.gotoPage(reference) navigates back to the editor normally The test still validates exactly what it was designed to verify: that the "Saved" notification appears and the form is disabled when Save & View is clicked. Also note: the @IgnoreBrowser(value = "chrome") annotation is now unnecessary since we no longer use alert handling. To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications