In this case, the server has no way of knowing that the user has pressed the stop button; it will continue to process the request and return the response page. This page will then be ignored or discarded by the browser. As a result, there could be a state synchronization issue between the client and the server. If the WebObjects application is storing state on the server, this will always be the case; the user will still see the original page, but the WebObjects application on the server will think that the client has moved on to the next page. This gives the same result as if the client had pressed the "Back" or "Previous" button on their server and accessed a cached page.
In most cases, where state is stored on the client, in cookies or hidden fields, the stop button will have no effect on the session. However, it is possible that a cookie which is storing state could be updated without the page being updated; this would cause a similar synchronization issue to that caused by the server-side state storage discussed above.
Whether state is stored on the client or on the server, there will be no other ill effects caused by the stop button; the WebObjects application will complete its normal request-response loop and remain in a normal post-processing state until it receives another request. In general, if you know that a particular operation will take a long time to complete, consider using the WOLongResponsePage. This will immediately return a page asking the user to wait and optionally displaying the status of a request. For more information on WOLongResponsePage, see the class documentation or the LongRequest example that is part of the WebObjects 4 distribution. For more information on dealing with state synchronization issues and the browser "Back" button, see the state management sections of the WOInfoCenter.