Browsers have been around for a few years now, its bad that some things that most developers need are still so difficult/kludgy. Why is still a pain to tell the difference between the user closing the browser and using the back/forward history buttons ? Yes I recently tangled with OnBeforeUnLoad.
Microsoft ( rightly ) get castigated because IE is not the worlds most CSS complient browser. But in this case the problem is the standards dont seem to address a common and simple development need.
When somebody logs on to our software a row gets created in a SQL table. They logout and the row is deleted. If they are already logged on they cant login again as the same user. Instead an administrator needs to go in and unlock them. This is part of our licencing system. A issue comes in the ASP.NET version of one of our applications, the user can just close the browser instead of clicking logout. So we needed to make the software logout the user however they exit the browser. ( Short of killing the task in task manager ). My manager, not unsensibly, expected this to be a trivial thing to code. Well its not rocket science but theres way too many steps here.
I have used AJAX.NET before but this project hasnt got any more needs for AJAX calls at present, downloading the latest version of AJAX.NET shows that more changes to web.config are needed over the earlier version I had used before. Seemed silly to do all that and add another DLL just for this.
OK I could handle keypresses, look for backspace or forward keys and set the global ignore logout request variable. This gets worse. And it still doesnt help if user presses the backspace button.
Change of thinking came with the realisation that I cannot have my logout code fire only when the user closes the browser window ( Installing browser addons isnt an option because its horrible and because our application users might be in an internet cafe ).
So instead I decide to live with the fact that the user record will get deleted if the users uses the history feature. To counter this each page must readd the record if its gone. So now the logon process stores all the information it needs to reinsert this record in session state. Each pages page_load method checks for this missing record and readds it if needed. In the extremely unlikely event that the user logged on with the same username, e.g. into the WIN32 application, the browser has to tell them this and prevent further actions until they logout of there.
In this case the logon record is purposely deleted as this page is loaded. So if they exit the browser when displaying the report all is OK, they are already logged out. If they backspace to the previous page then page_load on this page takes care of putting the record back.
So everything worked out but boy that was a lot of hoops to jump through !
It introduces a maintenance issue in that any new webpages added must make this ( one line ) call to ensure the user record is there. Maybe I could do away with this by adding a descendant of the Page class and having all my pages descend from there, or by adding the logic into the HTTP pipeline elsewhere - but this way is at least easy to understand when reading the code and it works.