IE can't do this either.

The standard doesn't well indicate whether onunload should be called when a browser window is closed, or if the browser is closed, or when the page is changed. It says:

W3C Event Model Specification for 'onunload' : "The onunload event occurs when the user agent removes a document from a window or frame. This attribute may be used with BODY and FRAMESET elements."

Since techincally, the document is never in a window or frame ( it's on a server silly! ) there's no real necessity to implement onunload, or onload >_>

Seriously; browser developers shouldn't implement this EVER. It's too much of an annoyance. You get 'web developers' making sites that have onload="return false;" onunload="window.location = 'elsewhere'" onunload="window.open('dont_leave.html')" onunload="while(1){alert('Come back!');}" et-cetera.

Opera doesn't call onunload, when going backwards and forwards between pages - with good reason; it remembers javascript state between pages; thus, the javascript is not unloaded in the normal sense. I suppose then, in Opera certainly, you're more likely to get an unload fired if and and only if the browser is closed. However, I'm pretty sure that closing the application stops javascript, thus ignoring remaining events. It should.

Firefox, I don't know. Do they remember JS state through navigation history?

> Firefox, I don't know. Do they remember JS state through navigation history?
Yes, only when the user doesn't provide an 'onunload' event handler. Read more about caching in Firefox.

Plus as far as I know, there is a bug in Opera related to the 'onunload' event.

Heh. I read that article and comments before making the post.. I'm firmly on the "it's not a bug" side of the fence, although it may or may not be a misinterpretation of the specification, which is another matter entirely. Looking at that Mozilla link makes me think that Opera have done it better ( by avoiding it ).

It has annoyed me in the past, that onunload doesn't work the same everywhere. But I can't think of a single case where it's truely neccessary to do something when a user 'unloads' a page, at least not any case that can't be worked around by looking at the problem in a different way.

Besides; you can never tell if a user turns the computer off, or sends a terminate signal to the browser, or unplugs their net connection ( ok, you can.. but you can't tell which one they did ).

It seems that you have never interacted with clients who insist on having a 'popup' window or some clean up routines to be performed when the user attempts on closing or unloading the window. Though this may seem like a nonsense requirement for public domain sites, it becomes a nifty feature for intranet sites.

Even Google makes use of this confirmation thingy (try composing a mail and going back to inbox without sending it) by either using the 'onunload' event or some other trick for rich and interactive user experience. Come to think of it, when you think of web revolution in terms of applications which behave more and more like the desktop applications, the onunload suddenly seems to be a required feature.

Think out of the box and you would see of the different ways in which you can use such events for the betterment of applications as well as UI.

My personal experience has been that Opera scales the worst when it comes to handling events displaying the most random behavior.

hi,
this code works fine but not like we want, to check if browser getting closed we need to get the x,y co-ed where mouse get clicked, if its less than 0 then its getting closed. but to send an event in firefox we need to perform some action like it says click "Hello There", event will go when we'll click Hello There, but we want to send the event onunload, which is ok with IE but not with FF, firefox sends event unintialized/undefined, so its hard to find the co-ed and to check it FF getting closed or not.

Such a nonsense!@
What a demagogy, hahahaha

Really not nonsense, There's nothing in standard HTML + JS that mandates the existance of a _window_ let alone an event when it closes. Each browser handles its idea of a 'window' in a different way. Maybe this is a shortcoming in HTML + JS, but, that's just the way it is.

Standards ?!
"Browser window" meaning "a browser".
The so called "Standards" don't indicate if internet should exist at all neither, but it exists.

On top of a sillynes of W3C using the word "remove" the document from the window..., when the correct word is "unloading" the document from the window, (that is: the window of interpreter application for particular document equipped with browsing capability) and you
saying that the "document is on the server" is more than wrong . Because if it was possible to view documents residing on a server without downloading them first - we would be surfing the net with the speed of light. Wouldn't we?!

You are somehow managing to ignore the fact that it's impossible for the page to get rendered and displayed before it gets cached. So practically, technically theoretically or whatever, - that statement is false. Because the page is loaded on the browser and that, smart browser will always know when it has started loading; when it has become interactive and also when it finished loading. Less smart browsers don't know when the page has started loading neither when it became interactive etc but they suddenly become aware of it only when it allready finished loading. Other dumber browsers shouldn't know this either.

I have to agree that old static generation browsers don't need the onload event to fire at all 'cause they can't do a thing with it. It is loaded when it loads.

This sounds as if you're proposing that we shuld go back to the time when you could use only html tags? I have to admit - life would be so damn easy, -but boring.

You are again missing the "target" - or is it the "source element"?
Are you suggesting that browser developers are to blame that you visit "x*x" webpages? That we should sue browser developers, because coders of some irresponsible barely legal agencies are forced to use advanced browser capabilities, in near criminal manner like some you've just mentioned?

Guess Not!
Your "target" is not the "source" of evil. Nothing is evil by itself. It depends on "who" is using it and of course "how". Shortly:WhoHow
It all depends on coders like you and me. - You should never allow yoursef to missuse a perfect browser functionality... If you buy a gun and kill an inocent, it's not the manufacturers fault, it's yours.

p.s.:
And you are also wrong when saying that if it only works in internet explorer it doesn't work. Pure internet dogma. Only ie6 has a sharee of more than 50% of browser agents, without counting lower ie versions and a great share ie7 has.

On contrary, in real world if something doesn't work in ie, will surely mean that it doesn't work at all. Since IE's are more than 70% of the browsers that will hit your page.


Smart browsers should make a distinction between: navigating away from the current page and/or from the current domain etc against application close.
But they don't!
I guess opera decided to neglect this event completely. Because events either happen - or they don't; in casse they happen, and there is a listener, - they get "on TV" no matter what. But in Operas casse the listener is not engaged.


There you are, - you've made a good point.


I totally agree. Opera is a beautiful browser but its to damn non "traditional" in its behavior, especially when it comes to keyboard navigation.

As for the question asked: i think our friend should change the aproach to hisproblem and see what others are using for the same purpose; google keyword "session expire" purhaps?

In my comment about the document being on a server; I'm pointing at the sillyness you also note in the W3C's wording: that of an implied concept of a browser 'removing' a document from some kind of tangible 'window'. Regardless of caching ( which isn't mandated by HTML either and is thus an 'implementation detail' ), the document is never actually 'moved' anywhere, just copied. When a browser actually unloads a document is even more difficult to define, though. It's not effecient to actually 'unload' all pages when going back and forth through them. ( EDIT: or, in terms of video memory, it's effecient to 'unload' the graphical manifestation of a page when ALT+Tabbing.. is this desired?.. This part of the standard hasn't really been updated since tabbed browsing/more interactive sites became popular, but, it's what you/we have to deal with )

I want webpages to stay mostly static, yes. Do what you want within reason at the server, but send HTML + CSS + simple JS to the client.. This model is 'traditional', and works for nearly everything that a person might use the World Wide Web ( i.e. a browser ) for. The 'application' model ( i.e. GUIs, realtime, events, etc ) is nearly always better served by actual applications; be those Internet-enabled or otherwise. There's too many reasons why for me to list here without writing a small essay, but I'm sure you know what I mean..

I wouldn't suggest going backwards; just moving forwards in the right direction.

I can't find a point in your comments on my signature; for explanation, I'm saying "design your site so it works in my alternative standards-compliant browser, or I don't consider it to be a working website". I don't really give a rats about the market share of another browser if all I see is an empty screen on primary browser : I just go elsewhere.