Window close

[Nagesh]

Hi All,

I have a requirement to handle the window(browser) close event.
When a user tries to close the browser window , we have to prompt him
whether he wants to
close the window or not. If yes no problem we can close . If no we
have redirect the page to some other
page.

Please help me on this.

Thanks & Regards,
Nagesh

 

[Merennulli]

Nagesh said the following on 9/6/2007 10:04 AM:



Your "requirement" is impossible to accommodate reliably.

That's just a matter of determining who you want to support. Most now
code for just Safari, IE6/7 and Mozilla.

Unfortunately you will probably have to resort to browser detection
for this one. The method I used in years past (returning false)
doesn't work on either Mozilla or IE, and the current recommended
method for IE doesn't work in Mozilla (which is probably why it's
recommended).

And if I simply navigate away from your site?

That isn't part of his requirement specification, but if he used
onbeforeunload to trigger this, it would handle both.

 

[Thomas 'PointedEars' Lahn]

That's just a matter of determining who you want to support.
True.

Most now code for just Safari, IE6/7 and Mozilla.

However, you have to define "most" (people) before you can make any
reasonable statement about that set of people. As you can not (you don't
know all [living] programmers, or their programming practice), your
statement is utterly useless.

It is also useless regarding the design decision that has to be made here.
If we would assume for an instant that you could be proven correct (which
is impossible), what most people do is not necessarily the best practice.

In fact, experience tells there is a huge number of people out there who
don't know, don't want to know, and don't need to know; a large number of
people who need to know and think they know but don't know; many people who
need to know and do know but don't understand how to apply their knowledge,
and only a few people who know what they are doing and can explain their
doing in understandable and reasonable terms. That is why newsgroups like
this one exist in the first place: so that the former group can learn from
the latter group, respectively.

Your suggestion identifies you as belonging to one of the groups mentioned
first in the list above.

Logical fallacy: Argumentum ad populum.


HTH

PointedEars

 

[korisu]

Randy/Thomas - depending on the scope of the application (wasn't quite
specified), this could be a system-audit requirement. Or, heaven
forbid, it might be a business requirement - the business types rarely
relent on many of these things.

In either case, Nagesh, your main problem is that the unload event
isn't cancelable. (http://www.w3.org/TR/2000/REC-DOM-Level-2-
Events-20001113/events.html#Events-eventgroupings-htmlevents) In IE,
you can use the onbeforeunload event, but before you do that, I'd
really suggest taking a look at what you're actually trying to
accomplish here. I recently helped another developer at work to
implement a better solution to a similar problem - when the user
closes the main window in our product, we have to log them out of the
system, and the way this was handled at first was by opening a new
window on unload, and that new window loaded a page that ran the
logout scripts. Then IE7 and its default popup-blocking broke that,
and someone quickfixed it by sticking a "Are you sure you want to
navigate away from the page?" confirm dialog into onbeforeunload. It
annoyed the piss out of everyone, because it stopped the user from
closing the browser cleanly, and forced the user to kill the process
on shutdowns. We replaced it with a tiny AJAX call to the logout
script on unload (didn't even need a callback function), and it's much
less irritating for everyone. So, if you have any influence on the
design of this part, I'd really recommend looking at it a different
way - if they're going to close the browser window, there's not much
you can do to truly stop them, and you might as well just grab as much
information as possible right there so that you can run your processes
on your own without them there.

And I'll agree with the others here that this is a straight-up suicide
mission if you're designing for the big bad Internet. Nothing kills
traffic to a site like annoyances. (Unless your site is targeted at
clueless masses of teenagers and rock bands, in which case you're
MySpace and I hate you. )

 

[Merennulli]

We replaced it with a tiny AJAX call to the logout

script on unload (didn't even need a callback function), and it's much
less irritating for everyone. So, if you have any influence on the
design of this part, I'd really recommend looking at it a different
way - if they're going to close the browser window, there's not much
you can do to truly stop them, and you might as well just grab as much
information as possible right there so that you can run your processes
on your own without them there.

I'm watching this thread because of the failure of something very
similar to this solution. The AJAX call isn't consistently finishing
in the time it takes the browser to close, and so the data is lost as
often as not. Is there something you're doing to keep the page open
until the AJAX call finishes?

In my case, a prompt IS an annoyance and would probably be
unacceptable to my users. I have other pieces of the same project,
though, where it might make sense. You have to realize that we are
moving into a new corporate paradigm where software is provided as a
web interface service, not as code you keep indefinitely on your local
computer, so some functionality such as "Save? Yes/no" prompts is not
only acceptable, but expected by the users. Both Adobe and Microsoft
have been working on such software, and it's modeled on projects from
the open source community.

As for telling the user something is impossible as Randy suggests, you
often have to demonstrate why something is impossible and make a good
faith effort to find a solution before you can alter a business
requirement. Just blithly telling your customers/boss that something
is impossible tends to be a poor career move. Yes, BOFH would be
proud, but we're paid to find solutions, not tell people what can't be
done (unless you're a consultant). At that, just because someone feels
it's impossible doesn't mean it is.

 

[Thomas 'PointedEars' Lahn]

As for telling the user something is impossible as Randy suggests, you
often have to demonstrate why something is impossible and make a good
faith effort to find a solution before you can alter a business
requirement. Just blithly telling your customers/boss that something
is impossible tends to be a poor career move. Yes, BOFH would be
proud, but we're paid to find solutions, not tell people what can't be
done (unless you're a consultant). At that, just because someone feels
it's impossible doesn't mean it is.

Nice try, but simply put a window.alert() call and show them what happens
"onunload" if they navigate away instead of closing the window. If they are
people that can be reasoned with they will have to agree that this is a bad
solution. Unfortunately, it is the only solution that is widely supported,
not only but also because the `unload' event is standardized per W3C DOM
Level 2 Events.

Or simply show them what happens with absent client-side script support,
with present but (partially) disabled client-side script support, or a not
so uncommon proxy that filters all scripts before they get to the user agent
due to security considerations.


PointedEars

 

[Merennulli]

Nice try, but simply put a window.alert() call and show them what happens
"onunload" if they navigate away instead of closing the window. If they are
people that can be reasoned with they will have to agree that this is a bad
solution. Unfortunately, it is the only solution that is widely supported,
not only but also because the `unload' event is standardized per W3C DOM
Level 2 Events.

Or simply show them what happens with absent client-side script support,
with present but (partially) disabled client-side script support, or a not
so uncommon proxy that filters all scripts before they get to the user agent
due to security considerations.

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

This is where your generalizations fail. No, it may not be a sound
philosophical argument, but in the real world we decide to what level
we're going to provide backwards compatability and alternative browser
options based on the current market and who our target audience is. If
the business requirement includes a prompt there, then it's very
possible that the target audience is a group that uses the specific
browsers that support a nonstandard solution. This "anybrowser" notion
is fine for public information, but not all applications have that
broad a userbase.

And to be blunt, if they are ASKING for it, showing them an alert box
where they want this is NOT going to disuade them.

Now can we quit with the useless sideline arguing and actually address
the question at hand?

 

[Thomas 'PointedEars' Lahn]

[...]
Just blithly telling your customers/boss that something
is impossible tends to be a poor career move. Yes, BOFH would be
proud, but we're paid to find solutions, not tell people what can't be
done (unless you're a consultant). At that, just because someone feels
it's impossible doesn't mean it is.

Nice try, but simply put a window.alert() call and show them what happens
"onunload" if they navigate away instead of closing the window. If they are
people that can be reasoned with they will have to agree that this is a bad
solution. Unfortunately, it is the only solution that is widely supported,
not only but also because the `unload' event is standardized per W3C DOM
Level 2 Events.

Or simply show them what happens with absent client-side script support,
with present but (partially) disabled client-side script support, or a not
so uncommon proxy that filters all scripts before they get to the user agent
due to security considerations.
[...]

Please trim your quotes when possible/reasonable, and don't quote signatures
(unless you are referring to them).

This is where your generalizations fail. No, it may not be a sound
philosophical argument, but in the real world we decide to what level
we're going to provide backwards compatability and alternative browser
options based on the current market and who our target audience is. If
the business requirement includes a prompt there, then it's very
possible that the target audience is a group that uses the specific
browsers that support a nonstandard solution. This "anybrowser" notion
is fine for public information, but not all applications have that
broad a userbase.

Your entire "real world" argument is inherently flawed because the user base
is primarily defined by the application itself and so the person developing
the application. In fact, for many applications, the user base could be
much greater and so the application could generate much more profit in the
mid-term and the long-term if only there was a competent and bold enough
person to point out that simple fact to the executives. I am trying hard
to, and, may I say, not with little success to date.

And to be blunt, if they are ASKING for it, showing them an alert box
where they want this is NOT going to disuade them.

Read again. I did not write you should do *that*, quite the opposite.

Now can we quit with the useless sideline arguing and actually address
the question at hand?

If that was a support forum where questions are to be answered in a way
that pleased the asking person most, that would be the logical thing to
do (to a certain extent).

But it isn't. The sooner you understand that, the sooner you will actually
start learning something here.


PointedEars