detect exiting the website

[Pif]

Hello, I've successed to capture de window closing event in my page.
This unload event is also generated when going to another page of the
website. I would like to be able to compare current URL with new one.
How can I get the information of the new URL (none if closing ?) ?

Thanks.

 

[Jeremy J Starcher]

Hello, I've successed to capture de window closing event in my page.
This unload event is also generated when going to another page of the
website. I would like to be able to compare current URL with new one.
How can I get the information of the new URL (none if closing ?) ?

Thanks.

No can do.

Why are you trying to detect if someone is leaving your web site?

 

[Pif]

We have an internal ERP. I need to modify session management to detect
that a user disconnects and to free his resources. So, I would like to
create following behaviour :
- modal window on close to nothing
- std window on close open dialog to suggest disconnection

 

[Sean Kinsey]

We have an internal ERP. I need to modify session management to detect
that a user disconnects and to free his resources. So, I would like to
create following behaviour :
- modal window on close to nothing
- std window on close open dialog to suggest disconnection

This is an approach that I use:
On onunload, open up a small window with window.open which contains a
script that waits a short duration and then attemts to access
window.opener.document.
If this succeeds then the document contained in the window is in the
same domain, and you can check the url. If it fails (try/catch) then
it has been navigated outside the domain.
Do the appropriate action and close the window.

 

[rf]

This is an approach that I use:
On onunload, open up a small window with window.open which contains a
script that waits a short duration and then attemts to access
window.opener.document.
If this succeeds then the document contained in the window is in the
same domain, and you can check the url. If it fails (try/catch) then
it has been navigated outside the domain.
Do the appropriate action and close the window.

And if the user simply closes their browser? Or pulls the computers plug out
of the wall?

Detecting what the OP wants is simply not possible. Any design that relies
on this is flawed and should be re-designed, as has been mentioned in many
newsgroups many many times.

 

[Thomas 'PointedEars' Lahn]

This is an approach that I use:
On onunload, open up a small window with window.open which contains a
script that waits a short duration and then attemts to access
window.opener.document.
If this succeeds then the document contained in the window is in the
same domain, and you can check the url. If it fails (try/catch) then
it has been navigated outside the domain.
Do the appropriate action and close the window.

I presume that opening a window onunload will already fail in the majority
of cases nowadays because of built-in popup blockers that are enabled by
default. Even if the popup is not blocked, there is a race condition with
the access to `window.opener.document', and a dependency on try-catch, in
particular relying on that a catchable exception will be thrown at all.

I must strongly recommend against this approach.

The proper approach, of course, is to let the server-side session expire on
inactivity, whereas as long as the ERP application is displayed the server
can optionally be pinged in the background via HTTP requests in regular
intervals that are shorter than the expiration interval, and to let the
server-side session expire explicitly on logout. It has been done before.


PointedEars

 

[Sean Kinsey]

I presume that opening a window onunload will already fail in the majority
of cases nowadays because of built-in popup blockers that are enabled by
default.  Even if the popup is not blocked, there is a race condition with
the access to `window.opener.document', and a dependency on try-catch, in
particular relying on that a catchable exception will be thrown at all.

I must strongly recommend against this approach.

The proper approach, of course, is to let the server-side session expire on
inactivity, whereas as long as the ERP application is displayed the server
can optionally be pinged in the background via HTTP requests in regular
intervals that are shorter than the expiration interval, and to let the
server-side session expire explicitly on logout.  It has been done before.

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

A server-side expiration quite similar to the one you explained is the
main approach, the popup is only there to allow for a faster reset
(not having to wait for the session to expire before being allowed to
log in again etc.)
And the user has in most cases allowed popups from the application in
order to access certain features, so for them it does work.

Why would you say that there is a race condition?

 

[Thomas 'PointedEars' Lahn]

A server-side expiration quite similar to the one you explained is the
main approach,

Not at all.

the popup is only there to allow for a faster reset (not having to wait
for the session to expire before being allowed to log in again etc.)

You can and SHOULD do that without the popup.

And the user has in most cases allowed popups from the application in
order to access certain features, so for them it does work.

The application should avoid popup windows to begin with. For one, they
are a resource killer and a hindrance to usability.

Why would you say that there is a race condition?

You know neither when the popup has finished loading (the opener can be
faster than the popup code), nor do you know when the new document is
displayed in the opener or when the `document' property of the opener will
be available for the read access to fail reliably enough (the popup code
can be faster than the opener).

Please trim your quotes to the relevant minimum
<http://jibbering.com/faq/#posting> pp.


PointedEars

 

[Sean Kinsey]

Not at all.

Since when did you gain detailed information about our application
architecture?

You can and SHOULD do that without the popup.

So how do you propose to inform the server immediately about a client
navigating/closing the window then?
I'm really looking forward to you answer here.

The application should avoid popup windows to begin with.  For one, they
are a resource killer and a hindrance to usability.

Seriously, you have no knowledge of the application mentioned, so to
come with such generalized statements are just silly. But hey, thats
pretty much all to expect around here..
If its a requirement to not navigate the main window AND to open a
secondary window/frame then this is not possible without window.open.
Or maybe once again you have some secret trick up you sleeve?

You know neither when the popup has finished loading (the opener can be
faster than the popup code)

who cares about this as the code is hosted IN the popup? It will run
when it loads..,

, nor do you know when the new document is

displayed in the opener or when the `document' property of the opener will
be available for the read access to fail reliably enough (the popup code
can be faster than the opener).

again, you know nothing of the application so stop generalizing.
The code uses a delay to give ample time load.
If its a document on the same domain then I know it will need little
time(single document app, so it's always a refresh) (and don't start
with dropped connections and all that nonsense), the read will succeed
and the popup does nothing.
If it doesn't load fast enough and the read fails due to that, or if
it fails due to SOP then I perform an action.

 

[Thomas 'PointedEars' Lahn]

Since when did you gain detailed information about our application
architecture?

That is a stupid question. Your application architecture has nothing to do
with the fact that the server-side solution that I have suggested has
nothing to do with the client-side solution that you have suggested.

So how do you propose to inform the server immediately about a client
navigating/closing the window then?
I'm really looking forward to you answer here.

See below.

Seriously, you have no knowledge of the application mentioned,

It is not necessary to know the application for this statement to be true.

so to come with such generalized statements are just silly.

It is not silly, it is a fact. And if you knew a first thing about the
Web, you would know this.

But hey, thats pretty much all to expect around here..
If its a requirement to not navigate the main window AND to open a
secondary window/frame then this is not possible without window.open.

Yes, it is.

Or maybe once again you have some secret trick up you sleeve?

Use e.g. an Image instance, a frame or iframe or XHR. The odds are better
that any of this works because it does not require the creation of a new
viewport beforehand, especially not a popup window.

who cares about this as the code is hosted IN the popup? It will run
when it loads..,

When it may be either too early or too late. You are either assuming that
the browsers must wait for the popup to be fully loaded before navigating
away, or that the browser must navigate away first and then open the popup.
Both assumptions are wrong.

again, you know nothing of the application so stop generalizing.
The code uses a delay to give ample time load.

"Ample time"? You know *nothing* about the user's environment, their
connection properties, and the response time of the server hosting the
other Web site that is navigated to.

If its a document on the same domain then I know it will need little
time(single document app, so it's always a refresh) (and don't start
with dropped connections and all that nonsense),

It is not nonsense, it is a fact that you cannot reliably determine that
way if and when the user has navigated away from the Web site.

the read will succeed and the popup does nothing.

Wishful thinking.

If it doesn't load fast enough and the read fails due to that, or if it
fails due to SOP then I perform an action.

You are ignoring the distinct possibility that accessing the property can
fail for another reason, in which case you would still "perform an action"
(or so you can hope, assuming try-catch support and a catchable exception),
much to the user's disadvantage.


PointedEars

 

[Sean Kinsey]

That is a stupid question.  Your application architecture has nothing to do
with the fact that the server-side solution that I have suggested has
nothing to do with the client-side solution that you have suggested.

Now your'e just being daft

See below.

Again, seriously. You suggest using "eg. an Image instance, a frame or
iframe or XHR" in the current document in the onunload event to notify
the server that the session should be terminated? Now we can talk
about race conditions...
And how are you going to detect whether the user is leaving the site,
navigating to a different page on the site, closing the window, or
just refreshing??
I'm looking forward to your follow up..

It is not necessary to know the application for this statement to be true..

Then, by that argument, no Programs should ever by run, as they
consume resources, and definitely not in browsers.

It is not silly, it is a fact.  And if you knew a first thing about the
Web, you would know this.

Again, your'e generalizing.
And by the way, congrats on discovering the fact that opening a new
window consumes resources. A discovery like that will likely
revolutionize the 'Web'.

Yes, it is.


Use e.g. an Image instance, a frame or iframe or XHR.  The odds are better
that any of this works because it does not require the creation of a new
viewport beforehand, especially not a popup window.

So you actually suggest opening a HTML document created to be used as
a user interface with an Image tag? Or via XHR?
If you knew a first thing about the Web, you would know this cannot be
done.

When it may be either too early or too late.  You are either assuming that
the browsers must wait for the popup to be fully loaded before navigating
away, or that the browser must navigate away first and then open the popup.
Both assumptions are wrong.

Again, its you that are making assumptions, way to many assumptions.
If you even knew what this was about you would see that it can never
be to late, only to early (the opener not having started the
navigation).
All other scenarios constitutes a failure (window closed, SOP in
effect)

hence the delay. And quite frankly, I don't care why it fails as long
as it is. It serves my purpose (which you are assuming a lot about).

"Ample time"?  You know *nothing* about the user's environment, their
connection properties, and the response time of the server hosting the
other Web site that is navigated to.

If you knew what you were talking about you would know that the server
hosting the other web site has nothing to do with it, and the test
would fail due to the SOP (as designed) anyway.
And just to be clear; for all you know its the location property I'm
testing, not the document it self. This would be affected by the SOP
from the first moment the document was navigated.

It is not nonsense, it is a fact that you cannot reliably determine that
way if and when the user has navigated away from the Web site.

Wait a minute, didn't you just give me some brilliant solution using
an Image and whatnot?

Wishful thinking.


You are ignoring the distinct possibility that accessing the property can
fail for another reason, in which case you would still "perform an action"
(or so you can hope, assuming try-catch support and a catchable exception),
much to the user's disadvantage.

Yes, I'm ignoring the fact that it can fail due to the neighbors 4x4
crashing through the wall and severing the power to the computer.

 

[Thomas 'PointedEars' Lahn]

Now your'e just being daft

And you can't write, or think clearly.

Again, seriously. You suggest using "eg. an Image instance, a frame or
iframe or XHR" in the current document in the onunload event to notify
the server that the session should be terminated?

No. As you well know, I have suggested something completely different.
But if I would go down your road I would certainly prefer the above over
your popup.

Now we can talk about race conditions...

No doubt about that. I have not said that it would be reliable, only that
it would be less error-prone than what you proposed.

And how are you going to detect whether the user is leaving the site,
navigating to a different page on the site, closing the window, or
just refreshing??

I am not. To do that was an unwise approach to begin with. AISB, I would
use scripting to ping the server in regular intervals while the user is
*on* the site instead, and set the session timeout to a few minutes. That
way, any user action that involves a roundtrip to the server would refresh
the session. And if client-side scripting would be supported, the session
need not even time out when the user did nothing (but to display the ERP
site while they are having a working network connection).

Then, by that argument, no Programs should ever by run, as they
consume resources, and definitely not in browsers.

"Resource killer" means that resources are allocated for the object that
are not fully released even though the object is no longer used.

So you actually suggest opening a HTML document created to be used as
a user interface with an Image tag?

Obviously not.

Or via XHR?

I am not suggesting "opening a HTML document". The (X)HTML document is
already *there*; however, while it is required to provide the runtime
environment for the client-side script, it is of course not required
as container for the object that causes the signaling HTTP request.

Again, its you that are making assumptions, way to many assumptions.
If you even knew what this was about you would see that it can never
be to late, only to early (the opener not having started the
navigation).

I have said "either ... or ...". Repair your logic module.

All other scenarios constitutes a failure (window closed, SOP in
effect)

There are non-failing scenarios that would be recognized as failure that
you apparently want to ignore.

hence the delay.

Which is very far from being reliable, of course. That is the race
condition produced by you, while risking the inherent one.

And quite frankly, I don't care why it fails as long as it is.

You don't care that the server is notified about a logout when no such
thing has happened?

It serves my purpose (which you are assuming a lot about).

By coincidence.

If you knew what you were talking about you would know that the server
hosting the other web site has nothing to do with it,

Wrong. A TCP connection needs to be made after DNS resolution took place.
It depends on the used DNS servers and on the host thus being connected to
when the connection is established. If the user runs into an almost-
timeout, there is a good chance that your script would simply not recognize
the navigation because it runs too early.

and the test would fail due to the SOP (as designed) anyway.

You miss the point.

And just to be clear; for all you know its the location property I'm
testing,

This is the first time that you mention that.

not the document it self.

Oh really?

,-<|
| On onunload, open up a small window with window.open which contains a
| script that waits a short duration and then attemts to access
| window.opener.document.

This would be affected by the SOP from the first moment the document was
navigated.
Pardon?


Wait a minute, didn't you just give me some brilliant solution using
an Image and whatnot?

See above.

Yes, I'm ignoring the fact that it can fail due to the neighbors 4x4
crashing through the wall and severing the power to the computer.

Argument at ridicule.


PointedEars

 

[Sean Kinsey]

Sean Kinsey wrote:

No.  As you well know, I have suggested something completely different. 
But if I would go down your road I would certainly prefer the above over
your popup.

Then you completely misunderstood the premises of this discussion.
I have already stated that yes, what you advocate should be the
primary function; what we are discussing here is the supplementary
'quick-notify' function.
It is an invalid argument to say that the first can replace the second
when the premises for the second is that it does something not
possible by the first.

I am not.  To do that was an unwise approach to begin with.  AISB, I would
use scripting to ping the server in regular intervals while the user is
*on* the site instead, and set the session timeout to a few minutes.  That
way, any user action that involves a roundtrip to the server would refresh
the session.  And if client-side scripting would be supported, the session
need not even time out when the user did nothing (but to display the ERP
site while they are having a working network connection).

See the first point

Obviously not.

Obviously you are. That is; since you assumed my above statement "open
a secondary window/frame" referred to signalling instead of presenting
the user with a new document, then I'm assuming that you are referring
to presenting a document instead of signalling.

I am not suggesting "opening a HTML document".  The (X)HTML document is
already *there*; however, while it is required to provide the runtime
environment for the client-side script, it is of course not required
as container for the object that causes the signaling HTTP request.

How high are you?
See my answer above.

I have said "either ... or ...".  Repair your logic module.

And how is that relevant to my argument?
As already stated several times, the function in the popup would be
delayed. It would always run after the opening document has navigated/
closed.
That is, unless the code running after the opening took seeeeriously
long to run, a scenario that I choose not to cater for.

You see, some of us actually do this for a living, that is, cater for
the 'real world' (Oh no, there I said it!).
I admit it, I will add a feature to a system I work with even if there
is a chance that in 0.00001% of its uses it will fail, and fail
without doing any real harm.

By coincidence.

I would say by arrogance

Oh really?

,-<|
| On onunload, open up a small window with window.open which contains a
| script that waits a short duration and then attemts to access
| window.opener.document.


Pardon?

Again you assume. You assume that the quick response given to the OP
is equal to what is implemented in a completely separate case.

Argument at ridicule.

Are you referring to 'Appeal to ridicule'?

 

[RobG]

A server-side expiration quite similar to the one you explained is the
main approach, the popup is only there to allow for a faster reset
(not having to wait for the session to expire before being allowed to
log in again etc.)
And the user has in most cases allowed popups from the application in
order to access certain features, so for them it does work.

Have you considered a logout button with encouragement for users to
use it? Since this seems to be an intranet application, users could be
taught to use it during their training in the application. You could
use server logs to see which users are timing-out and remind them that
to save resources, they should be using the logout button before
navigating away or leaving the application idle.

Another encouragement is to allow consistent users of the logout
button a longer session timeout, so they are rewarded for their
efforts.

Just suggestions, of course.

 

[Garrett Smith]

Have you considered a logout button with encouragement for users to
use it? Since this seems to be an intranet application, users could be
taught to use it during their training in the application. You could
use server logs to see which users are timing-out and remind them that
to save resources, they should be using the logout button before
navigating away or leaving the application idle.

What incentive does the user have to logout? I'm guessing that such
button would not have a big enough impact.

Just suggestions, of course.

Another idea would be to make a req, such as new Image, or XHR, as Lahn
stated, and use that to expire the session on the server. No guarantee
with that, but it would alleviate some server issues.

The pop up window is clearly not a good idea.

What you are doing is trying to provide extra code on the client to make
up for a problem on the server.

Did the experts at your company look into the session object on the
server? Am I going to far to call them experts? Chances are there are
more efficient ways of fulfilling requirements.

 

[Hamish Campbell]

We have an internal ERP. I need to modify session management to detect
that a user disconnects and to free his resources.

I'd hazard to guess that the sum economic cost of this thread is
already greater than than the cost of purchasing hardware to solve the
problem on the server end.

 

[Sean Kinsey]

Its not an intranet app, and we do have a signout button, and we do
encourage the users to use it.
The point here is not to expire the session, but to, if possible
expire the session faster than the main approach in cases where it is
not used.

What incentive does the user have to logout? I'm guessing that such
button would not have a big enough impact.


Another idea would be to make a req, such as new Image, or XHR, as Lahn
stated, and use that to expire the session on the server. No guarantee
with that, but it would alleviate some server issues.

It has already been discussed and this is still not possible to use.
It can, and is, used to persist the session, but cannot be used to
notify the server about a navigation due to the code not knowing if
the navigation is a safe refresh or not.

To propose the only way it _could_ work:
* In a pre-unload event, run a sync XHR/equivalent that modifies the
session to expire in a minute amount like 10 seconds.
* If the client does not issue a new request to the server, the
session expire normally
* If the client issues a new request before expiration, then the
regular session expiration extension mechanism kicks in and extends
the session.
Actually, I might just do the above, sounds like fun!

The pop up window is clearly not a good idea.

What you are doing is trying to provide extra code on the client to make
up for a problem on the server.

Not really. We have thousands of users, and some of these tend to do
stupid things like close the browser etc, does not answer the
appropriate answer from the dialog brought up by the onbeforeunload
event, and then opens a new browser to sign in again.
The 'extra code' on the client took about 30 min to write, and works
successfully as long as the popup is allowed.

Did the experts at your company look into the session object on the
server? Am I going to far to call them experts? Chances are there are
more efficient ways of fulfilling requirements.

<childsvoice>session object? whats that?</childsvoice>
Does it suffice to answer yes?

 

[Antony Scriven]

[...]

It has already been discussed and this is still not
possible to use. It can, and is, used to persist the
session, but cannot be used to notify the server about
a navigation due to the code not knowing if the
navigation is a safe refresh or not.

To propose the only way it _could_ work:
* In a pre-unload event, run a sync XHR/equivalent that
modifies the session to expire in a minute amount like 10
seconds.
* If the client does not issue a new request to the
server, the session expire normally
* If the client issues a new request before expiration,
then the regular session expiration extension mechanism
kicks in and extends the session.
Actually, I might just do the above, sounds like fun!

[...]

And what if the server requests arrive in an order different
from what you expected? --Antony

 

[Thomas 'PointedEars' Lahn]

To propose the only way it _could_ work:
* In a pre-unload event, run a sync XHR/equivalent that modifies the
session to expire in a minute amount like 10 seconds.
* If the client does not issue a new request to the server, the
session expire normally
* If the client issues a new request before expiration, then the
regular session expiration extension mechanism kicks in and extends
the session.
Actually, I might just do the above, sounds like fun!

Idiot. I have proposed that approach yesterday.

<

PointedEars

 

[Sean Kinsey]

Idiot.  I have proposed that approach yesterday.

Sure you did.. Was it in the post where you also proposed displaying
new HTML documents using Image?