Prevent window closing

Discussion in 'Javascript' started by danny, Dec 23, 2003.

  1. danny

    danny Guest

    Is there a way I can prevent the browser window from being closed? I'd
    like to make sure the browser window only closes programatically (I want
    to make sure the user enters data before moving on).

    Another possible solution would be to re-open the window when it's
    closed.

    Any help is appreciated, thanks.
    danny, Dec 23, 2003
    #1
    1. Advertising

  2. danny wrote:

    > Is there a way I can prevent the browser window from being closed?


    No. (Although porn sites with hundreds of blinking banner adverts would love
    it if it were possible)

    > I'd like to make sure the browser window only closes programatically (I
    > want to make sure the user enters data before moving on).


    This is the web. You can't force the user to do anything. Make the
    application robust enough to survive the user doing the unexpected.

    --
    David Dorward <http://dorward.me.uk/>
    David Dorward, Dec 23, 2003
    #2
    1. Advertising

  3. danny

    danny Guest

    In article <bsagsp$tg$1$>,
    says...
    > danny wrote:
    >
    > > Is there a way I can prevent the browser window from being closed?

    >
    > No. (Although porn sites with hundreds of blinking banner adverts would love
    > it if it were possible)


    I bet!

    > > I'd like to make sure the browser window only closes programatically (I
    > > want to make sure the user enters data before moving on).

    >
    > This is the web. You can't force the user to do anything.


    Actually, It's not for an internet application. I'm building a thin
    client application. It's a call center application, and when a contact
    is closed, they are supposed to enter data. Problem is, because it's a
    browser, they can just click the X mark and close the window, which
    leaves the contact waiting for data to move to another state. If I
    could pop the window back up and request the data again, that is
    acceptable, but I haven't yet figured that out.

    > Make the
    > application robust enough to survive the user doing the unexpected.


    Gee thanks... I thought that's what I *WAS* doing...
    danny, Dec 23, 2003
    #3
  4. danny

    @SM Guest

    danny a ecrit :
    >
    > In article <bsagsp$tg$1$>,
    > says...
    > > danny wrote:
    > >
    > > > Is there a way I can prevent the browser window from being closed?

    > >
    > > No. (Although porn sites with hundreds of blinking banner adverts would love
    > > it if it were possible)

    >
    > I bet!
    >
    > > > I'd like to make sure the browser window only closes programatically (I
    > > > want to make sure the user enters data before moving on).

    > >
    > > This is the web. You can't force the user to do anything.

    >
    > Actually, It's not for an internet application. I'm building a thin
    > client application. It's a call center application, and when a contact
    > is closed, they are supposed to enter data. Problem is, because it's a
    > browser, they can just click the X mark and close the window, which
    > leaves the contact waiting for data to move to another state. If I
    > could pop the window back up and request the data again, that is
    > acceptable, but I haven't yet figured that out.


    supose your funtion to send your data is
    function sendData(){ blah blah ; DataOk=1;}

    var DataOk =0;
    </script></head>
    <body onunload="if(DataOk==0) sendData();"

    Would works with IE
    @SM, Dec 23, 2003
    #4
  5. danny

    danny Guest

    In article <>,
    says...
    > danny a ecrit :
    > >
    > > In article <bsagsp$tg$1$>,
    > > says...
    > > > danny wrote:
    > > >
    > > > > Is there a way I can prevent the browser window from being closed?
    > > >
    > > > No. (Although porn sites with hundreds of blinking banner adverts would love
    > > > it if it were possible)

    > >
    > > I bet!
    > >
    > > > > I'd like to make sure the browser window only closes programatically (I
    > > > > want to make sure the user enters data before moving on).
    > > >
    > > > This is the web. You can't force the user to do anything.

    > >
    > > Actually, It's not for an internet application. I'm building a thin
    > > client application. It's a call center application, and when a contact
    > > is closed, they are supposed to enter data. Problem is, because it's a
    > > browser, they can just click the X mark and close the window, which
    > > leaves the contact waiting for data to move to another state. If I
    > > could pop the window back up and request the data again, that is
    > > acceptable, but I haven't yet figured that out.

    >
    > supose your funtion to send your data is
    > function sendData(){ blah blah ; DataOk=1;}
    >
    > var DataOk =0;
    > </script></head>
    > <body onunload="if(DataOk==0) sendData();"
    >
    > Would works with IE


    Would this prevent the window from unloading? Or would I have to handle
    that someplace else?
    danny, Dec 23, 2003
    #5
  6. danny

    Eric Bohlman Guest

    danny <> wrote in
    news::

    > Actually, It's not for an internet application. I'm building a thin
    > client application. It's a call center application, and when a
    > contact is closed, they are supposed to enter data. Problem is,
    > because it's a browser, they can just click the X mark and close the
    > window, which leaves the contact waiting for data to move to another
    > state. If I could pop the window back up and request the data again,
    > that is acceptable, but I haven't yet figured that out.


    You need to properly handle that on the server end since you also have to
    deal with contingencies like the client machine crashing, the client
    machine losing power, or a network outage, all of which could result in no
    data being entered at a particular state in the application.
    Eric Bohlman, Dec 23, 2003
    #6
  7. danny

    danny Guest

    In article <Xns945AB9C7281C7ebohlmanomsdevcom@130.133.1.4>,
    says...
    > danny <> wrote in
    > news::
    >
    > > Actually, It's not for an internet application. I'm building a thin
    > > client application. It's a call center application, and when a
    > > contact is closed, they are supposed to enter data. Problem is,
    > > because it's a browser, they can just click the X mark and close the
    > > window, which leaves the contact waiting for data to move to another
    > > state. If I could pop the window back up and request the data again,
    > > that is acceptable, but I haven't yet figured that out.

    >
    > You need to properly handle that on the server end since you also have to
    > deal with contingencies like the client machine crashing, the client
    > machine losing power, or a network outage, all of which could result in no
    > data being entered at a particular state in the application.


    Yes, the server side needs to be addressed as well (as you note, clients
    purposely closing the window isn't the only issue...) but the big
    problem is call transfer. When there's an outage, the switch drops the
    call, but when the client closes the window, the call is in limbo on the
    switch...
    danny, Dec 24, 2003
    #7
  8. danny wrote:

    >> This is the web. You can't force the user to do anything.

    >
    > Actually, It's not for an internet application.


    If its browser based, then its as good as.

    >> Make the
    >> application robust enough to survive the user doing the unexpected.


    > Gee thanks... I thought that's what I *WAS* doing...


    where the application is the code you execute on the server, not on the
    client which is beyond your control (at least if you use a normal web
    browser).

    --
    David Dorward <http://dorward.me.uk/>
    David Dorward, Dec 24, 2003
    #8
  9. danny

    @SM Guest

    danny a ecrit :
    >
    > In article <>,
    > says...
    > > danny a ecrit :
    > > >
    > > >
    > > > It's a call center application, and when a contact
    > > > is closed, they are supposed to enter data. Problem is, because it's a
    > > > browser, they can just click the X mark and close the window, which
    > > > leaves the contact waiting for data to move to another state. If I
    > > > could pop the window back up and request the data again, that is
    > > > acceptable, but I haven't yet figured that out.

    > >
    > > supose your funtion to send your data is
    > > function sendData(){ blah blah ; DataOk=1;}
    > >
    > > var DataOk =0;
    > > </script></head>
    > > <body onunload="if(DataOk==0) sendData();"
    > >
    > > Would works with IE

    >
    > Would this prevent the window from unloading? Or would I have to handle
    > that someplace else?


    that would launch your function about your state data
    after closing the window
    with IE it could (sometimes) works if IE is closed
    (doesn't work on an alt+shift+del or alt+F4 )

    to re-open the window try :

    function reBack(){
    open.window(self.location);
    alert('You have not completed the Data question');}

    <body onunload="reback();">

    or
    <body onunload="setTimeout('reback()',200);">
    @SM, Dec 24, 2003
    #9
  10. danny

    @SM Guest

    "@SM" a ecrit :
    >
    > to re-open the window try :
    >
    > function reBack(){
    > open.window(self.location);
    > alert('You have not completed the Data question');}
    >
    > <body onunload="reback();">
    >
    > or
    > <body onunload="setTimeout('reback()',200);">


    Take care you will never more can quite this page !

    You have to fix a conditional before

    <body onunload="if(!myData) reBack();">

    *myData* would be a global variable
    myData = false;
    changed to "true" by your function about your Data
    when it is called
    @SM, Dec 24, 2003
    #10
  11. danny

    Cues Plus Guest

    Well sort of:

    Here is some information on it:

    VBS/NoClose, JS.Trojan.NoClose
    Type: Trojan

    Detection: Detected by Sophos Anti-Virus since May 2002.

    Description: JS/NoClose is a JavaScript Trojan. When an affected website is
    accessed the Trojan will minimize Internet Explorer and attempt to access
    other websites without the user's express permission. These sites either
    contain advertisements or pornographic material.

    Michael
    --


    http://www.cuesplus.com
    http://www.cuesplusbilliards.com
    http://www.stixplus.com
    (remove SPAMBLOCK if replying by e-mail)
    "danny" <> wrote in message
    news:...
    >
    > Is there a way I can prevent the browser window from being closed? I'd
    > like to make sure the browser window only closes programatically (I want
    > to make sure the user enters data before moving on).
    >
    > Another possible solution would be to re-open the window when it's
    > closed.
    >
    > Any help is appreciated, thanks.
    Cues Plus, Dec 24, 2003
    #11
  12. danny

    Grant Wagner Guest

    danny wrote:

    > In article <Xns945AB9C7281C7ebohlmanomsdevcom@130.133.1.4>,
    > says...
    > > danny <> wrote in
    > > news::
    > >
    > > > Actually, It's not for an internet application. I'm building a thin
    > > > client application. It's a call center application, and when a
    > > > contact is closed, they are supposed to enter data. Problem is,
    > > > because it's a browser, they can just click the X mark and close the
    > > > window, which leaves the contact waiting for data to move to another
    > > > state. If I could pop the window back up and request the data again,
    > > > that is acceptable, but I haven't yet figured that out.

    > >
    > > You need to properly handle that on the server end since you also have to
    > > deal with contingencies like the client machine crashing, the client
    > > machine losing power, or a network outage, all of which could result in no
    > > data being entered at a particular state in the application.

    >
    > Yes, the server side needs to be addressed as well (as you note, clients
    > purposely closing the window isn't the only issue...) but the big
    > problem is call transfer. When there's an outage, the switch drops the
    > call, but when the client closes the window, the call is in limbo on the
    > switch...


    So you make the transaction atomic. That is to say, you don't change the state
    of the item in the database, then ask for additional information, because if
    the additional information is not forthcoming, the item will be in the incorrect
    state, with missing data.

    So instead, you record that you want to change the state of the item, you
    request the information, and then, only if all the data was received and
    validated properly, you change the state and update the data in the database.

    One way to do this might be to actually introduce a new "state" for the items,
    which says "the user requested a state change on this item", then when you
    recieve the additional data, you change it from that state to the completed
    state. That way, if the user requests a state change, then don't supply the
    additional data, you have a way of notifying them of items in a pending state
    change the next time they log in.

    1. User requests state change
    2. Change state from "open" to "pending closed"
    3. User supplies additional data
    4. If additional data is valid, change state from "pending close" to "close"

    The next time they log in, you query the database for items in "pending close"
    state and display "You have XX item(s) in a 'pending close' state, do you want
    to supply the additional data for these item(s) now?" If they chose not to do
    this, the items will remain in the "pending close" state and will be displayed
    the next time they log in, otherwise you execute the code path for #3 above,
    which allows them to supply the additional information, which completes the
    state change.

    --
    | Grant Wagner <>

    * Client-side Javascript and Netscape 4 DOM Reference available at:
    *
    http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

    * Internet Explorer DOM Reference available at:
    *
    http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

    * Netscape 6/7 DOM Reference available at:
    * http://www.mozilla.org/docs/dom/domref/
    * Tips for upgrading JavaScript for Netscape 7 / Mozilla
    * http://www.mozilla.org/docs/web-developer/upgrade_2.html
    Grant Wagner, Jan 2, 2004
    #12
    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. Daniel Walzenbach
    Replies:
    9
    Views:
    19,201
    sandip25pa
    Jan 25, 2010
  2. =?Utf-8?B?U2lsZWVzaA==?=
    Replies:
    4
    Views:
    33,871
    =?Utf-8?B?U29sZWwgU29mdHdhcmU=?=
    Oct 14, 2004
  3. Patrick Olurotimi Ige

    Closing child window when opening a new Window

    Patrick Olurotimi Ige, Dec 14, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    430
    Patrick Olurotimi Ige
    Dec 14, 2004
  4. =?Utf-8?B?Vk1J?=

    Closing popup window when closing parent window?

    =?Utf-8?B?Vk1J?=, Feb 14, 2007, in forum: ASP .Net
    Replies:
    3
    Views:
    643
    Thomas Hansen
    Feb 15, 2007
  5. thomas
    Replies:
    0
    Views:
    218
    thomas
    Oct 23, 2003
Loading...

Share This Page