When the user refreshes the page, a window close event will be raised for the main window.
This case is not originally distinguished from times when the browser is closed, in which case some resources should be relinquished!
Is it the way it’s supposed to be?
Thanks,
Houman.
ANY IDEAS? :bored:
Hey Houman,
I believe this is due to how browsers work. The event originates from the browser triggered javascript event for the main window closing, so I don’t straight away know how Vaadin could distinguish the two.
Perhaps the very smart people in the R&D department have better ideas? 
/Jonatan
I am the one to blame for this problem.
When you press a reload button, the browser immediately connects server and starts to load the contents from the URL. After a while (probably when the HTML-parser has parser enough of the page), the window.onunload event is called on the
previous
page. If I remember correctly, different browser implementations behaved a bit differently with this.
It would be great to be able to somehow (reliably) detect this situation from the server-side. Unfortunately we have not found a good way of doing it.
All prototypes are welcome :)
so until now there is no solution for make a different between two event, event when page refresh and when window close. Any solution for this becouse i need to using different action in this two condition event.
There is no good way to deal with this issue currently. Please describe your use-case - maybe there is a way to resolve it without solving the window.close event problem.
Opened a ticket for adding this to framework:
http://dev.vaadin.com/ticket/4586
Hi,
I have just posted ticket #5687 about this - so probably unnecessarily (I searched the tickets but not the forum for this topic before).
In my application I tried to use window close event to automatically logout the user (as an alternative to manual logout or session expiration) when he or she closes the browser. But generating the event also on page refresh made the idea unusable (user lost after refresh). Additional problem is the inconsistent behavior across opera and other browsers as described above. Could you suggest any better pattern ?
rootWindow.addListener(new CloseListener()
{
@Override
public void windowClose(CloseEvent e)
{
setUser(null);
}
});
Tomasz Barczyk
Hello,
Is there any solution for this problem?
Christophe
My experience with current versions of FF, Chrome, and IE is that they fire the window close event before the page reload is performed.
That allows us to wait e.g. 10s before finally closing the application. If we receive a new request within this period of time we stop our closing operation. I implemented the behavior in Scala (see code below). It works well in FF, Chrome, and IE. In Opera this doesn’t have any effect since Opera doesn’t inform the server about closing events.
class MyApp extends Application with HttpServletRequestListener { app =>
val closeTimer = new Timer("CloseTimer", true)
lazy val mainWindow = new Window("MyApp") {
onClose{
closeTimer.cancelRunningTasks()
// wait for 10s before closing the application, since this might be just a page reload
closeTimer.schedule(10000, app.close())
}
}
override def onRequestStart(request: HttpServletRequest, response: HttpServletResponse) {
// stop any closing tasks
closeTimer.cancelRunningTasks()
super.onRequestStart(request, response)
}
def init() {
setMainWindow(mainWindow.window)
}
}
class Timer(name: String, isDaemon: Boolean) extends java.util.Timer(name, isDaemon) {
private val runningTasks = new mutable.HashSet[TimerTask]
/** Executes the given action after the given duration. */
def schedule(delay: Long, action: => Unit) {
val task = new TimerTask {
def run() {
if (runningTasks.contains(this)) {
action
}
}
}
runningTasks += task
schedule(task, delay)
}
/** Cancels all running tasks gracefully. */
def cancelRunningTasks() {
try {
if (!runningTasks.isEmpty) {
runningTasks.clear()
purge()
}
} catch {
case e: IllegalStateException =>
}
}
}