detect exiting the website
in [JavaScript]
|
From: Sean Kinsey on 7 Apr 2010 17:01 On Apr 7, 10:20 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Sean Kinsey wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> 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. > >> > A server-side expiration quite similar to the one you explained is the > >> > main approach, > >> Not at all. > > > 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. Now your'e just being daft > > >> > 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. > > > 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. 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.. > > >> > 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. > > > Seriously, you have no knowledge of the application mentioned, > > 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. > > > 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. 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'. > > > 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. 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. > > >> > 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) > > > 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, 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) > > >> , 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). 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). > > > 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 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. > > > 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. Wait a minute, didn't you just give me some brilliant solution using an Image and whatnot? > > <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing> > > > 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. 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.
From: Thomas 'PointedEars' Lahn on 7 Apr 2010 18:11 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Sean Kinsey wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> Sean Kinsey wrote: >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> 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. >> >> > A server-side expiration quite similar to the one you explained is >> >> > the main approach, >> >> Not at all. >> > 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. > > Now your'e just being daft And you can't write, or think clearly. >> >> > 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. >> > 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. > > 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). >> >> > 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. >> > Seriously, you have no knowledge of the application mentioned, >> 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. "Resource killer" means that resources are allocated for the object that are not fully released even though the object is no longer used. >> > 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. > > 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. >> >> > 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) >> > >> > 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, 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. >> >> , 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). > > 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. >> > 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 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? ,-<news:49db9e1e-3cb8-4ed8-ba65-063451d9bb00(a)q23g2000yqd.googlegroups.com> | | 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? >> > 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. > > Wait a minute, didn't you just give me some brilliant solution using > an Image and whatnot? See above. >> > 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. > > 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 -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Sean Kinsey on 7 Apr 2010 19:15 On Apr 8, 12:11 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: <snip> > > 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. 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. <snip> > > 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). See the first point <snip> > >> > 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. > > > So you actually suggest opening a HTML document created to be used as > > a user interface with an Image tag? > > 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. > > > 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. How high are you? See my answer above. > >> >> > 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) > > >> > 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, 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. 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. <snip> > > It serves my purpose (which you are assuming a lot about). > > By coincidence. I would say by arrogance <snip> > Oh really? > > ,-<news:49db9e1e-3cb8-4ed8-ba65-063451d9bb00(a)q23g2000yqd.googlegroups.com> > | > | 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? Again you assume. You assume that the quick response given to the OP is equal to what is implemented in a completely separate case. <snip> > >> 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. > > Argument at ridicule. Are you referring to 'Appeal to ridicule'?
From: RobG on 7 Apr 2010 19:36 On Apr 7, 9:47 pm, Sean Kinsey <okin...(a)gmail.com> wrote: [...] > 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. -- Rob
From: Garrett Smith on 7 Apr 2010 21:32
RobG wrote: > On Apr 7, 9:47 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > [...] >> 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. > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |