Stopping navigation away from the page

[Yash]

Hi,

In our ASP .NET application we present a form wherein the user has to
input a number of fields. If in the middle of filling the form, the
user accidentally navigates away from the page, either by clicking a
link on the page or hitting an entry in the Favorites or in any way,
we want to present an alert with only the OK button, which when
clicked will keep the user on the same page and avoid the navigation
out of the page.

If we do it in the onbeforeunload event, we get a standard popup with
OK and CANCEL. When Cancel is clicked, the user navigates away. We
want to avoid this.

Can you please suggest a way? Is there a way to capture the navigation
event and suppress it?

Thanks,
Yash

 

[GArlington]

Hi,

In our ASP .NET application we present a form wherein the user has to
input a number of fields. If in the middle of filling the form, the
user accidentally navigates away from the page, either by clicking a
link on the page or hitting an entry in the Favorites or in any way,
we want to present an alert with only the OK button, which when
clicked will keep the user on the same page and avoid the navigation
out of the page.

If we do it in the onbeforeunload event, we get a standard popup with
OK and CANCEL. When Cancel is clicked, the user navigates away. We
want to avoid this.

Can you please suggest a way? Is there a way to capture the navigation
event and suppress it?

Thanks,
Yash

1) What is the point in presenting only one option "OK"? Are you
working for early Microsoft (an error occurred - click "OK" to
continue)?
2) If the user does not have a choice then there is NO point in
presenting the box, but you can still use std alert()
3) If you put this script in onUnload event, your user will NEVER be
able to leave the page, or are you going to put some code in Submit
button onClick event to disable the onUnload code?

 

[Stevo]

If we do it in the onbeforeunload event, we get a standard popup with
OK and CANCEL. When Cancel is clicked, the user navigates away. We
want to avoid this.

That sounds like a bad idea. Why would you want to not allow a user to
leave ? I agree catching them and asking if they're sure they want to
abandon what they were doing is a good idea, but preventing them from
doing it doesn't sound sensible.

 

[Yash]

That sounds like a bad idea. Why would you want to not allow a user to
leave ? I agree catching them and asking if they're sure they want to
abandon what they were doing is a good idea, but preventing them from
doing it doesn't sound sensible.

I want to present only an OK because the user should be made aware of
why he is not being allowed to leave. When he cliks OK, he will be
back on the page.

There will be special flag set onclick of the Submit button to exempt
it from the above check. So only on Submitting, the user will be able
to leave the page.

This is a client requirement and we have no control over it.

 

[GArlington]

I want to present only an OK because the user should be made aware of
why he is not being allowed to leave. When he cliks OK, he will be
back on the page.

There will be special flag set onclick of the Submit button to exempt
it from the above check. So only on Submitting, the user will be able
to leave the page.

You (and your client) will find a lot of angry ex-customers who will
just close the site window in order to never to come back.

This is a client requirement and we have no control over it.

You (as a developer) should suggest to your client that they should
rethink their strategy - you can not trap free people and expect them
to be happy about it.

 

[Stevo]

This is a client requirement and we have no control over it.

I certainly don't feel fine offering the solution to that. I would feel
bad if I told someone how to trap people in web pages and that was used
for adware type tactics. I'll pass.

 

[seani]

You (and your client) will find a lot of angry ex-customers who will
just close the site window in order to never to come back.




You (as a developer) should suggest to your client that they should
rethink their strategy - you can not trap free people and expect them
to be happy about it.

True enough in an Internet app., a lot less clear-cut on an intranet.
Personally I'd never use an internet site that insisted on trapping me
in this way. On a private intranet where you're using DHTML/JS as a
mechanism to front other business processes, it could be perfectly
acceptable.

A bit more context from the OP might help.

 

[Thomas 'PointedEars' Lahn]

You (and your client) will find a lot of angry ex-customers who will
just close the site window in order to never to come back.

I think they will have a hard time doing that, as clicking close causes the
event listener for the ' beforeunload` event to be executed. Those
then-furious ex-customers will have to kill the browser process in order to
continue working, which is why they are going to tell all their friends,
collegues and family to avoid this stupid Web site like hell in favor of the
plenty other ones out there that would be advertising the same thing, only
in an accessible way.

You (as a developer) should suggest to your client that they should
rethink their strategy - you can not trap free people and expect them
to be happy about it.

Full ACK.


PointedEars

 

[Thomas 'PointedEars' Lahn]

If we do it in the onbeforeunload event, we get a standard popup with
OK and CANCEL. When Cancel is clicked, the user navigates away. We
want to avoid this.

I think you mean when "OK" is clicked, the user navigates away. And you do
want this, trust me.

Can you please suggest a way? Is there a way to capture the navigation
event and suppress it?

Furtunately, there is not. Besides, the only thing the user has to do to
for prison break is to disable client-side script support to a sufficient
extent (if event present), and never come back again.

You really want to rethink your approach.


PointedEars