A lot of webpages are now done with AJAX (fancy Javascript) or just Javascript. This allows a webpage to remain responsive even though your session has timed out and and you’ve been logged off by the web server. You may even be able to navigate to a “compose email” page without server interaction, which makes you think that you’re still online and can compose and send email.
Well, you can compose to your heart’s content because it’s still being handled locally by the browser but when you try to send the email, you get the “session expired” raspberry from the server because your session timed out long ago. Oh, and by the way, your work has disappeared too!
I got bitten by this a few dozen times before I developed this simple (though annoying) workaround: before you ask for the “compose email” page, first do a “check email”. If you’ve been logged off, you’ll find out before you waste time writing something that will be lost. If you’re still logged in, at least it will restart the session expiration timer so you’re less likely to be logged off while you’re composing your email.
Nowadays, I try to realize ahead of time whether something I’m writing will take a while. (Notice that this could happen even with a short email because you can be interrupted by something, anything.) During peak hours when the session expiration times seem to get shorter, I try to remember to save composed email text to a separate, local editor session so that I can be philosophical about the server silently logging me off before I try to send the email.
One could ask why the Javascript doesn’t just back up “email composed so far” to a local file before the server expires your session. First, that would require additional server interaction, which programmers are trying to minimize. Second, it breaks the simple paradigm of user-initiated actions. Third (and most importantly) it means granting the webpage the ability to save files to disk without user input (a big security issue).
You could argue that the webpage could ask the user first, but remember that we’re dealing with a scenario where the user might have walked away from the computer to deal with an interruption and is unable to grant that permission quickly enough to satisfy the web server. There is still the possibility of squirrelling the email away in browser memory somewhere, but that implies extra user interface complexity that the email programmers haven’t seen fit to provide.
Remember that browser technology was invented to enable hypertext browsing, not rich client interaction. However, rich client features have been tacked on using hacks that are either clever, hideous or both. Until the bugs are worked out, or we’re all using Outlook or some other local, non-web-based email client, we’ll need workarounds like the one suggested to smooth the way.