detect exiting the website

Discussion in 'Javascript' started by Pif, Apr 6, 2010.

  1. Pif

    Pif Guest

    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.
     
    Pif, Apr 6, 2010
    #1
    1. Advertising

  2. On Tue, 06 Apr 2010 14:11:33 -0700, Pif wrote:

    > 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?
     
    Jeremy J Starcher, Apr 6, 2010
    #2
    1. Advertising

  3. Pif

    Pif Guest

    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

    On 6 avr, 23:30, Jeremy J Starcher <> wrote:
    >
    > Why are you trying to detect if someone is leaving your web site?
     
    Pif, Apr 7, 2010
    #3
  4. Pif

    Sean Kinsey Guest

    On Apr 7, 9:25 am, Pif <> wrote:
    > 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.
     
    Sean Kinsey, Apr 7, 2010
    #4
  5. Pif

    rf Guest

    Sean Kinsey wrote:
    > On Apr 7, 9:25 am, Pif <> wrote:
    >> 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.


    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.
     
    rf, Apr 7, 2010
    #5
  6. Sean Kinsey wrote:

    > Pif wrote:
    >> 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.


    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.)
     
    Thomas 'PointedEars' Lahn, Apr 7, 2010
    #6
  7. Pif

    Sean Kinsey Guest

    On Apr 7, 12:26 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Sean Kinsey wrote:
    > > Pif wrote:
    > >> 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.

    >
    > 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?
     
    Sean Kinsey, Apr 7, 2010
    #7
  8. Sean Kinsey wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Sean Kinsey wrote:
    >> > 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.

    >
    > 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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Apr 7, 2010
    #8
  9. Pif

    Sean Kinsey Guest

    On Apr 7, 7:19 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Sean Kinsey wrote:
    > > Thomas 'PointedEars' Lahn wrote:

    <snip>
    > >> 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?

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

    >
    > > 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, 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?

    >
    > > 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..,

    , 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.
     
    Sean Kinsey, Apr 7, 2010
    #9
  10. 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.

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

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

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

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

    >> , 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.


    "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.

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


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Apr 7, 2010
    #10
  11. Pif

    Sean Kinsey Guest

    On Apr 7, 10:20 pm, 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

    >
    > >> > 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.
     
    Sean Kinsey, Apr 7, 2010
    #11
  12. 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:>
    |
    | 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
     
    Thomas 'PointedEars' Lahn, Apr 7, 2010
    #12
  13. Pif

    Sean Kinsey Guest

    On Apr 8, 12:11 am, Thomas 'PointedEars' Lahn <>
    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:>
    > |
    > | 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'?
     
    Sean Kinsey, Apr 8, 2010
    #13
  14. Pif

    RobG Guest

    On Apr 7, 9:47 pm, Sean Kinsey <> 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
     
    RobG, Apr 8, 2010
    #14
  15. RobG wrote:
    > On Apr 7, 9:47 pm, Sean Kinsey <> 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/
     
    Garrett Smith, Apr 8, 2010
    #15
  16. On Apr 7, 7:25 pm, Pif <> wrote:
    > 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.
     
    Hamish Campbell, Apr 8, 2010
    #16
  17. Pif

    Sean Kinsey Guest

    On Apr 8, 3:32 am, Garrett Smith <> wrote:
    > RobG wrote:
    > > On Apr 7, 9:47 pm, Sean Kinsey <> 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.


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


    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?
     
    Sean Kinsey, Apr 8, 2010
    #17
  18. 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
     
    Antony Scriven, Apr 8, 2010
    #18
  19. Sean Kinsey wrote:

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

    <news:>


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Apr 8, 2010
    #19
  20. Pif

    Sean Kinsey Guest

    On Apr 8, 11:37 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > Sean Kinsey wrote:
    > > 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.


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

    >
    > <news:>
    >
    > PointedEars
    > --
    >     realism:    HTML 4.01 Strict
    >     evangelism: XHTML 1.0 Strict
    >     madness:    XHTML 1.1 as application/xhtml+xml
    >                                                     -- Bjoern Hoehrmann
     
    Sean Kinsey, Apr 8, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jiten

    exiting from state machine

    jiten, Jun 22, 2005, in forum: VHDL
    Replies:
    3
    Views:
    503
  2. Anne
    Replies:
    0
    Views:
    376
  3. =?Utf-8?B?Qm9uag==?=

    problem with aspnet exiting

    =?Utf-8?B?Qm9uag==?=, Nov 11, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    348
  4. =?Utf-8?B?YmJkb2J1ZGR5?=

    Exiting an ASP.net application

    =?Utf-8?B?YmJkb2J1ZGR5?=, Jun 24, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    537
    samitha
    Sep 21, 2006
  5. BrainC
    Replies:
    8
    Views:
    2,237
    JustSomeGuy
    Sep 11, 2003
Loading...

Share This Page