This component is a work in progress. Currently it works only for Selenese commands type and typeRandom.


Modern web pages assist you to prevent unintended loss of the data that you entered. When you edit a form but you don’t submit it and then you try to close the tab (or the window or the browser), or you try to navigate away from the screen (following links or typing a new URL), the page asks you to confirm your intention. In Firefox it says ‘This page is asking you to confirm that you want to leave - data you have entered may not be saved.’ and it gives you a choice of two buttons: ‘Stay on Page’ and ‘Leave Page’. (You won’t be able to close the tab/window or even Firefox unless you click at one of those buttons, or unless you close Firefox forcibly). The application asks for that confirmation in a handler for window.onbeforeunload().

This is not limited to unsubmitted forms. The web application may have two or more pages which store user’s inputs/actions in the session, and only on the further pages the application saves/submits that data. If you try to close or navigate away from the website after it stored some data in the session but before it saved/submitted the data, it should confirm your intention.

Also, say you have an application that attracts your attention (e.g. an alert from a calendar or an email client). Then the application may use the same confirmation method to increase the likelihood that you read the alert.

ExitConfirmationChecker helps your scripts to validate that the application asks for this confirmation exactly when it should. (It doesn’t add any Selenese commands.)

What it does for you

This component suppresses the confirmation dialog activated from window.onbeforeunload(). If that’s all you need, use mode ignored. The other two active modes includeRevertedChanges and skipRevertedChanges also verify (or assert) whether the confirmation popup would show up (or would not show up) as it should.


Out-of-the-box ExitConfirmationChecker only handles

Reverted changes (or zero changes)

A script may select a new value for a field and then change it back to its original value, or type content in a free-type field same as its original content (or type something else and then type the original content back). The application may keep a list of original values of the fields and then treat such a field as unchanged. Otherwise it treats such a field as unchanged. ExitConfirmationChecker can validate both behaviours. You can configure which behaviour your application uses.


This uses Settings with standard module extensions.selite-settings.common and fields exitConfirmationCheckerAssert and exitConfirmationCheckerMode. exitConfirmationCheckerAssert indicates whether the defects in showing (or not showing) the confirmation should result in Selenese assertion failure (like failing any assertXyz command). Otherwise such defects only result in verification failure (like failing any verifyXyz command). exitConfirmationCheckerMode can be


Here are a few rules of thumb:


This validates effect of a command only just before running the next command. However, it uses configuration present for that next command. This can get highly confusing when running multiple suites via SeLite Run All Favorites, if they have different configuration and the last command of a suite (other than the last suite) modifies an input or (re)loads the page.

If you run a whole case (or suite), you don’t set exitConfirmationCheckerAssert, and the previous command fails ExitConfirmationChecker validation, then ExitConfirmationChecker logs an extra error. That’s because of a workaround for ThirdPartyIssues > verify* should show the diff. Otherwise, when you run a single Selenese command (by double-clicking) and the command fails ExitConfirmationChecker validation, there would be no message in the log at all. Please vote for that issue and for other ThirdPartyIssues.

Scripts (tests)

Follow PackagedScripts for Selenese scripts of Exit Confirmation Checker. See source of form.html, SeLiteSettingsValues.txt and the actual scripts. Test cases with name starting with negative are supposed to fail: see PackagedScripts > Negative tests that fail.