Having sessions expire can be important for security, but if your users take to long editing, it can cause them to lose content.
We have the alert box, which stops JS execution, appear about 10 minutes before the session expires. If the user hits OK on the alert box, the AJAXy code does a roundtrip to the server which refreshes the session timer. If they don't hit OK, the session times out as planned.
A little more complex method would be to check the IsDirty flag to see if the user has made any changes, or listen for events being fired through our advanced APIs.
An alternative approach is to simply let the session expire but make it possible to login again without losing the content. One way of doing this is to allow the user to login using standard HTTP authentication, where the browser displays a dialog asking for login information, instead of using a HTML form to login. The browser will automatically resend the POST data after it logs in so the content won't be lost. You can use a HTML form for login normally and only use HTTP authentication when you're handling POST requests to have the best of both worlds.
If you stick with using a form to login all the time, you could simply include the original POST data in hidden fields so that it isn't lost and once the user logs in correctly you can save the content for them. Most login systems already do something like this to remember the original URL the user was trying to access.
Depending on your backend systems, there are a range of ways you can remove the frustration of session timeouts and let users take as long as they need to edit content. If none of the options above work for you, you could always make your sessions last longer which will at least make the problem less frequent.