Checking when browser is closing

[Laser Lips]

Hello all. I've looked on Google and it appears there is no
definitive way of checking when someone closes a browser.
I need to perform a load of things when the browser closes and need to
check when the browser shuts down.
How do you deal with it?

Graham

 

[David Mark]

Hello all. I've looked on Google and it appears there is no
definitive way of checking when someone closes a browser.
I need to perform a load of things when the browser closes and need to
check when the browser shuts down.
How do you deal with it?

You don't. Sorry.

 

[Stevo]

Hello all. I've looked on Google and it appears there is no
definitive way of checking when someone closes a browser.
I need to perform a load of things when the browser closes and need to
check when the browser shuts down.
How do you deal with it?

Graham

There are the onunload and onbeforeunload events, but they're not unique
to a "closing" browser. They fire just the same if somebody navigates
elsewhere. You can't be guaranteed to get them though (e.g. if someone
hard-closes the browser from the task manager). Also, you're limited in
some browsers to what you can do in a handler from these events. For
example, in Safari you can't make any http requests (they'll be blocked).

It might be better if you explain the things you need to do as there may
be better alternatives.

 

[Laser Lips]

I'm working with a technology called CACHE which is made by
Intersystem’s.

I need to do a couple of things when the browser closes.

I need to log the user out of the system.
I need any locks in the CACHE database to be unlocked.
CACHE will not know when the browser closes because like any server
side technology, it does not have a permanent connection to the
browser.

I can't have Ajax polling the server because there will be to many
server calls.
I really need these locks to be taken off immediately.
If the user exists using the log out buttons then these locks are
removed, it's just when they hit the [X] that I can't catch.

Graham

 

[Stevo]

I'm working with a technology called CACHE which is made by
Intersystem’s.

I need to do a couple of things when the browser closes.

I need to log the user out of the system.
I need any locks in the CACHE database to be unlocked.
CACHE will not know when the browser closes because like any server
side technology, it does not have a permanent connection to the
browser.

I can't have Ajax polling the server because there will be to many
server calls.
I really need these locks to be taken off immediately.
If the user exists using the log out buttons then these locks are
removed, it's just when they hit the [X] that I can't catch.

Graham

Some sites use auto-logout timeouts both client side and (with a
slightly longer timeout) server side. No good for you?

Hooking into the onunload or onbeforeunload and logging out from there
would certainly help (although not with Safari as I mentioned).

 

[rf]

I'm working with a technology called CACHE which is made by
Intersystem’s.

So why don't you ask them how they do what you wish to do?

I need to do a couple of things when the browser closes.

I need to log the user out of the system.
I need any locks in the CACHE database to be unlocked.
CACHE will not know when the browser closes because like any server
side technology, it does not have a permanent connection to the
browser.
Exactly.

I can't have Ajax polling the server because there will be to many
server calls.
I really need these locks to be taken off immediately.
If the user exists using the log out buttons then these locks are
removed, it's just when they hit the [X] that I can't catch.

Doomed to failure.

What if the user simply turns their computer off? What if there is a power
failure?

What if their browser crashes? What if the operating system crashes? What if
they simply re-boot?

What if their internet connection fails?

What if they throw their computer out the window?

You will *never* be able to determine if any of these things have happened,
so why bother checking if the browser has "closed". You can't, reliably. You
need to find some other method of cleaning up your server side processes.

 

[Laser Lips]

What if the user simply turns their computer off? What if there is a power
failure?

What if their browser crashes? What if the operating system crashes? What if
they simply re-boot?

What if their internet connection fails?

What if they throw their computer out the window?

You will *never* be able to determine if any of these things have happened,
so why bother checking if the browser has "closed". You can't, reliably. You
need to find some other method of cleaning up your server side processes.

OK, I get your point. Will think of something.

Graham

 

[David Mark]

OK, I get your point. Will think of something.

As mentioned, a server side session timeout is the best bet.

 

[Evertjan.]

David Mark wrote on 02 mrt 2010 in comp.lang.javascript:

As mentioned, a server side session timeout is the best bet.

Even better, do not keep things "open" between browser and server during
the session but store the intermediate result if you don't want the the
result in the database until your user signals a completion.

On start of a new session ask the user if he wants to resume his work. m/f

 

[Laser Lips]

David Mark wrote on 02 mrt 2010 in comp.lang.javascript:





Even better, do not keep things "open" between browser and server during
the session but store the intermediate result if you don't want the the
result in the database until your user signals a completion.

On start of a new session ask the user if he wants to resume his work. m/f

Not as simple as all that.

While a user has a record open that record is locked to all other
users.
The mechanism we use to lock a record is CACHE's built in one.
We could use temporary tables to flag locked records and use temporary
storage until user is ready top commit data back to the DB but this
means a whole software rewrite and many site updates, so it's out of
the question.

All records are unlocked after 15 mins or a session timeout, but the
intermittent waiting is a real killjoy.
Graham

 

[Evertjan.]

Laser Lips wrote on 02 mrt 2010 in comp.lang.javascript:

Not as simple as all that.

As much as I hate topposting, this full bottomquoting is also not
perfect. So please skip all irrelevant parts, like the signature.
Any good newsreader will do the latter for you automagically.

And start interposting.

While a user has a record open that record is locked to all other
users.

So that is clearly not the way to do it. If you cannot use a roll back
mechanism, just do not process the data till everything is ready for the
final datetranfer tot te database.

The record locking should be only miliseconds long.

The mechanism we use to lock a record is CACHE's built in one.

So if it is a bad system, don't use it.
Is this ASP?
VBS or Jscript?
or is this a com?

We could use temporary tables to flag locked records and use temporary
storage until user is ready top commit data back to the DB but this
means a whole software rewrite and many site updates, so it's out of
the question.

Your choice. If it is too much work to better the procedure, it usually
is the logical alternative option to keep using the bad and the ugly.

All records are unlocked after 15 mins or a session timeout, but the
intermittent waiting is a real killjoy.

Quite so.

You should be able to shorten that timeout to 1 minute, but still ...

 

[Musaul Karim]

While a user has a record open that record is locked to all other
users.
The mechanism we use to lock a record is CACHE's built in one.
We could use temporary tables to flag locked records and use temporary
storage until user is ready top commit data back to the DB but this
means a whole software rewrite and many site updates, so it's out of
the question.

All records are unlocked after 15 mins or a session timeout, but the
intermittent waiting is a real killjoy.
Graham

It's almost always a bad idea in web based system to lock any server
resource beyond the span of a single request. This is especially true
if you are going to have enough users to make ajax based polling
unfeasible.

If the data involved here takes a while to edit, then you might
yourself need to implement a more granular locking, i.e. field level?

Like everyone here has already said, there is no guaranteed method the
browser/client connection is no longer available. If you want a
lighterweight polling system, perhaps you could try a raw sockets
connection using Java or Flash? I haven't done any benchmarks to see
how much lighter it would be though.

 

[rf]

Not as simple as all that.

While a user has a record open that record is locked to all other
users.
The mechanism we use to lock a record is CACHE's built in one.
We could use temporary tables to flag locked records and use temporary
storage until user is ready top commit data back to the DB but this
means a whole software rewrite and many site updates, so it's out of
the question.

All records are unlocked after 15 mins or a session timeout, but the
intermittent waiting is a real killjoy.
Graham

It's interesting that the daily FAQ posting of 3.5 hours ago deals exactly
with what you are trying to do.