detect exiting the website

[Sean Kinsey]

On Apr 8, 8:58 am, Sean Kinsey wrote:

 > [...]
 >
 > 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

That was the point of the "sync XHR/equivalent" statement, to ensure
this request has run prior to the actual navigate event.
But as some would say, 'what if the network goes down and the request
cannot be completed?'; well, that has no negative effect compared to
the primary solution.

 

[Thomas 'PointedEars' Lahn]

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

So you can't read, too.


PointedEars

 

[Scott Sauyet]

Idiot.  I have proposed that approach yesterday.

<news:[email protected]>

When you proposed that solution, Sean responded

| 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

You didn't seem to notice that Sean understands that a server-side
solution is the only completely reliable one, that he is using a
client-side solution to improve the user's experience when possible.
And as server-side session expiry is frequently in the 30-minute-
range, this can be a substantial improvement for the user who forgets
to log out.

The solution he suggests above goes further than your original
suggestion, though, by modifying (on page unload) the server-side
timeout to a much shorter period. I don't know how well the solution
will work. It strikes me as a bad idea for a browser to allow *any*
HTTP requests inside the page unload, but I know that window.open(url)
does work so maybe a synchronous XHR request will too.

I'm not saying that I would support Sean's suggestion, but you are not
doing him justice with your insults.

-- Scott

 

[Antony Scriven]

[... about automatic log out ...]

[...] Sean understands that a server-side solution is the
only completely reliable one, that he is using a
client-side solution to improve the user's experience
when possible. [...]

The solution he suggests above goes further than your
original suggestion, though, by modifying (on page
unload) the server-side timeout to a much shorter period.
I don't know how well the solution will work. It strikes
me as a bad idea for a browser to allow *any* HTTP
requests inside the page unload, but I know that
window.open(url) does work so maybe a synchronous XHR
request will too.

Synchronous requests don't tend to improve the user's
experience. --Antony

 

[Jorge]

Synchronous requests don't tend to improve the user's
experience. --Antony

But onunload you can't do an asynchronous XHR.

 

[Sean Kinsey]

But onunload you can't do an asynchronous XHR.

Perhaps not, but I have seen it done in onbeforeunload.

 

[Sean Kinsey]

Perhaps not, but I have seen it done in onbeforeunload.

The code at http://kinsey.no/code/xhronunload/ runs successfully on
onunload in current versions of Firefox, Chrome, Safari and Internet
Explorer, and also in IE 6.
I didn't take the time to get the onunload event in Opera to fire, so
I don't know about that one.

 

[Jorge]

The code athttp://kinsey.no/code/xhronunload/runs successfully on
onunload in current versions of Firefox, Chrome, Safari and Internet
Explorer, and also in IE 6.
I didn't take the time to get the onunload event in Opera to fire, so
I don't know about that one.

....syncrhonously: xhrObj.open('GET', "index.html", **false**);

 

[Sean Kinsey]

...syncrhonously: xhrObj.open('GET', "index.html", **false**);

^^^^^^^^^^
What was that about?

 

[Sean Kinsey]

...syncrhonously: xhrObj.open('GET', "index.html", **false**);

Right, you said asynchronous earlier. But then I said synchronous from
the start

 

[Jorge]

Right, you said asynchronous earlier. But then I said synchronous from
the start

Yes, I know
I was pointing out to Scriven that onunload that's the only way to
XHR.
(synchronously)

 

[Antony Scriven]

But onunload you can't do an asynchronous XHR.

I wasn't talking about asynchronous XHR. --Antony

 

[Jorge]

On Apr 8, 7:00 pm, Jorge wrote:

 > > Synchronous requests don't tend to improve the user's
 > > experience. --Antony
 >
 > But onunload you can't do an asynchronous XHR.

I wasn't talking about asynchronous XHR. --Antony

But any other attempt to fetch an additional resource onunload might
fail. I.e. an <img>. E.g. in Safari.

 

[Antony Scriven]

But any other attempt to fetch an additional resource onunload might
fail. I.e. an <img>. E.g. in Safari.

Don't do that either. --Antony

 

[Sean Kinsey]

On Apr 8, 4:24 pm, Scott Sauyet wrote:

 > [... about automatic log out ...]
 >
 > [...] Sean understands that a server-side solution is the
 > only completely reliable one, that he is using a
 > client-side solution to improve the user's experience
 > when possible. [...]
 >
 > The solution he suggests above goes further than your
 > original suggestion, though, by modifying (on page
 > unload) the server-side timeout to a much shorter period.
 > I don't know how well the solution will work.  It strikes
 > me as a bad idea for a browser to allow *any* HTTP
 > requests inside the page unload, but I know that
 > window.open(url) does work so maybe a synchronous XHR
 > request will too.

Synchronous requests don't tend to improve the user's
experience. --Antony

Generalizing with 'blocking the ui thread is bad and therefor
synchronous xhr is bad, so this approach MUST be bad' is just silly.
In this case it is proven exactly the opposite.
Since the result of the synchronous xhr is an improved user experience
then it can be deducted that using a synchronous xhr in onload (for
this scenario) actually does improve the user experience.

I do not generalize and say that all use of synchronous xhr improves
ux (now that would also be silly), just that _in this case_ it
actually does.

 

[Antony Scriven]

[...]

Generalizing with 'blocking the ui thread is bad and
therefor synchronous xhr is bad, so this approach MUST be
bad' is just silly. In this case it is proven exactly the
opposite.
How?

Since the result of the synchronous xhr is an improved
user experience then it can be deducted that using
a synchronous xhr in onload (for this scenario) actually
does improve the user experience.

What happens if your app is open in two windows? --Antony

 

[Jorge]

On Apr 8, 9:37 pm, Jorge wrote:

 >
 > > On Apr 8, 7:00 pm, Jorge wrote:
 >
 > > > > Synchronous requests don't tend to improve the user's
 > > > > experience. --Antony
 > > >
 > > > But onunload you can't do an asynchronous XHR.
 >
 > > I wasn't talking about asynchronous XHR. --Antony
 >
 > But any other attempt to fetch an additional resource onunload
might
 > fail. I.e. an <img>. E.g. in Safari.

Don't do that either. --Antony

So, what do you propose to ping the server from onunload ?

 

[Sean Kinsey]

On Apr 9, 9:51 am, Sean Kinsey wrote:

 > [...]
 >
 > Generalizing with 'blocking the ui thread is bad and
 > therefor synchronous xhr is bad, so this approach MUST be
 > bad' is just silly. In this case it is proven exactly the
 > opposite.

How?

Read the thread...

 > Since the result of the synchronous xhr is an improved
 > user experience then it can be deducted that using
 > a synchronous xhr in onload (for this scenario) actually
 > does improve the user experience.

What happens if your app is open in two windows? --Antony

That has not been covered here, but for our application that is not
possible within the same browser and so does not need to be accounted
for.

 

[Antony Scriven]

On Apr 9, 9:51 am, Sean Kinsey wrote:

[...]

Generalizing with 'blocking the ui thread is bad and
therefor synchronous xhr is bad, so this approach
MUST be bad' is just silly. In this case it is proven
exactly the opposite.

How?

Read the thread...

`Read the thread...' really means `I don't have any real
proof but I'm hoping you'll get lost reading the thread and
aren't going to notice.'

That has not been covered here, but for our application
that is not possible within the same browser and so does
not need to be accounted for.

And what happens when you upgrade? --Antony

 

[Antony Scriven]

So, what do you propose to ping the server from onunload ?

Sean's approach seems to be:

1. On navigating away from a page in the application,
send the server a message saying that you can
terminate my session now.

2. But if you've navigated to a page in the same app,
then send the server a message saying `Hey, I haven't
really navigated away, disregard my last message!'

That's got to be asking for trouble. My apologies if I've
misunderstood.

It would be safer to start pinging the server as soon as you
connect to a page to let it know that you are still
connected. But why bother? If server resources are so low
that terminating users' sessions after two minutes (or
whatever) rather than thirty will really make that much
difference, then the problem lies elsewhere. It's the
server's responsibility to maintain its own resources. --Antony