You wouldn't want to do it on Page_Unload, as that is part of the normal ASP.NET page lifecycle and fires once the page has been fully rendered - so it would release the worklist item right as the user was getting to see it on the screen (http://msdn.microsoft.com/en-us/library/ms178472(v=vs.100).aspx).
There are many other ways you could handle this in the approach you're trying to take (watching for the user to close the window) - such as handling the html body onunload event or something similar. But with these methods, you need to build in logic to make sure not to fire when the user follows links, or submits forms, etc.
What we implement in all of our forms is a "close" button and a "release and close" button along with all of the other action buttons for the user (see image below). We have done this ever since we started building forms for our workflows. When the user clicks the "close" button, it will simply close the form keepint it allocated to that user. When the user clicks that "release and close" button, it will close the form and release the worklist item so others may action the worklist item as needed. We provide both buttons, because we have use cases where workflows are assigned to a group of people in specific steps and someone will take one from the pool and will want to keep it until they have actioned it. Others may simply open in and return it back to the pool by releasing it.
Agreed. Trying to accomplish this in ASP.NET or Javascript is going to be a painful, sad experience. We take a similar approach as described by @mike.
We have also taken it a step further and granted "admin" users the ability to release tasks for another user. This is accomplished by using the K2 API and a WCF service. This same service also allows those "admin" users to redirect an activity to another user or terminate a process if needed. This way, all process management is pushed from the IT department back to the business owners of a process. These methods are all in the SourceCode.Workflow.Management API namespace.
The only catch with it is that users taking these actions have to have admin rights on the process. We weren't comfortable giving lots of folks admin rights on a process, so we created the WCF service. We created an AD account with admin rights on all processes. The WCF service then runs in a dedicated IIS app pool whose identity is that of the AD account.
