Hi Friends..
In my web application(ASP.net), i need to disable the "Back" button in the browser.Moreover i also need to disable the Backspace key in my keyboard when my web page is run..How to do it with javascript..? Someone help with javascript as early as possible..
Regards,
Balaguru
You can't disable the back button. The best you can do is to open a new window with JavaScript and remove that toolbar. But if the page loads in a window with the toolbar you can't disable it.
You also can't disable the keyboard but you can use JavaScript to ignore certain keys from being acted upon. You need to intercept the event and then ignore it.
HI
how to disable IE back button , as my jsp page conatins 3 frames , so how can i disable/ stop the operation of back/forward button.
regards
sandeep.
Sorry Sandeep..
It caused a lot of problems for me..I gave it up..
Regards,
Balagurunathan S
Both of you need to read my post. I gave you the answer in there.
using
<script>
function disable()
{
document.getElementById("").Disable=true
}
</script>
<body>
using this function in ur onclick="disable()" method
</body>
That doesn't work for the back button since it isn't part of the web page.
The "Back" button belongs to the user, not to you. You have no right to disable it, since it might be the only way the user has to return to the page he came from to get to your page.
I have seen people use such tricks as removing the toolbar or forwarding to a second page. These make me mad at the programmer, because he denies me the opportunity to complete my tree search of a Google request or another website.
The annoyance with the 'Back' button, I fear is not universal. There are cases (read Intranet applications) where the client has requirements for the web application to look like a desktop application, making the removal of toolbars necessary.
BalagurunathanS, the only way to disable the back button is to remove the entire toolbar in the way mentioned by Midimagic in his previous post.
For Intranet applications; it's much easier to control the browser being used to access the page... Open VB6, drop WebBrowser control on form, don't add any buttons that call the control's 'back' event; save; compile; backbutton-neutered IE6. Distribute to everyone onsite.
In any context, including Intranet applications, why should 'back' ever need to be disabled? Just accept it's there, and that it goes back ( to potentially anywhere ); and incorporate that into your plans. Don't overlook it up to the point that it becomes a problem.
> backbutton-neutered IE6. Distribute to everyone onsite.
Being Intranet doesn't mean we can assume that all the clients would be using the browser / OS of our choice, not to mention you already included a proprietary software there by mentioning VB. Basically there are several contributing factors, the clients' requirements being the most important of them all. The popup window method will work for all browsers.
> In any context, including Intranet applications, why should 'back' ever need to be disabled?
Crazy clients, crazy requirements.
Wouldn't have to VB, could be C++ et al since the control's an ActiveX, and the same principle applies to all OS that package commonly used components/objects/etc. I was using VB as an example. Could even be done in Java, although not easily.. Alternatively, modify a Firefox version, it's opensource and multiplatform ( maybe write once compile anywhere? no idea ). Intranet implies internal, and companies often control the software on their employees machines.
The popup window method will only work if the browser allows popups, and there's nothing to stop a user re-enabling the toolbar on a popup, or accessing the page without following a path that invokes the popup (i.e direct URL ) still, it's probably a better solution than writing a new browser frontend just to disable 'back'..
I still can't imagine a good reason to disable back. What's the ultimate intention? There will be other means to achieve the same aims ( unless those aims are ultimately to disable back ) without disabling back. That's not to say that those means wouldn't always require any replanning or large modifications; which is why it's a good idea to recognise 'back's' ( and equally 'refresh's' ) existance early on.
Wouldn't have to VB, could be C++ et al since the control's an ActiveX, and the same principle applies to all OS that package commonly used components/objects/etc. I was using VB as an example. Could even be done in Java, although not easily.. Alternatively, modify a Firefox version, it's opensource and multiplatform ( maybe write once compile anywhere? no idea ). Intranet implies internal, and companies often control the software on their employees machines.
All those things would be quite a PITA and I really mean _quite_. Java, yes can be done, but feasible, never. Active-X again MS proprietary. C++, zero feasibility, at least when my ultimate aim is not making a browser. All the options are too much just for disabling a back button or increasing the display area by removing the toolbar.
The popup window method will only work if the browser allows popups, and there's nothing to stop a user re-enabling the toolbar on a popup, or accessing the page without following a path that invokes the popup (i.e direct URL ) still, it's probably a better solution than writing a new browser frontend just to disable 'back'..
Intranet applications almost always run in trusted zone so popups won't be a problem unless you specifically plan on disabling them, though it doesn't make any sense as to why someone would disable an intended feature.
I still can't imagine a good reason to disable back.
Increasing the display area, restricting user navigation, giving the feel of desktop applications, naive guarding against the infamous back button syndrome when using AJAX etc.
>> Increasing the display area, restricting user navigation, giving the feel of desktop applications,
Fair enough, but one doesn't need to disable back functionality for this, you might want a popup, or just provide fullscreen browsing instructions. The backbutton's actual functionality is irrrelevant here, since the intention is, I guess, to remove the toolbar. You still can't stop the user pressing backspace, or having some registered shortcut that does 'back', or even showing the toolbar; but, I guess in these cases, that wouldn't matter since the reason that the button can't be seen is purely superficial.
>> naive guarding against the infamous back button syndrome when using AJAX etc.
It's a naive and unreliable means for restricting or controlling any part of an underlying application. Anything the user couldn't do without a backbutton, they could do by some other means; trying to hack out the backbutton because it messes with some assumption in the application is addressing the wrong part of the problem.
I guess the OP is making some kind of quiz site wherein he doesn't want the user to switch to the previous questions. In that case, implementing this using the server side language of one's choice is the best possible way, IMO.
> It's a naive and unreliable means for restricting or controlling any part of an underlying application.
Yes, I guess that's what I said in my previous post.
>> Being Intranet doesn't mean we can assume that all the clients would be using the browser / OS of our choice
>> Intranet applications almost always run in trusted zone so popups won't be a problem unless you specifically plan on disabling them, though it doesn't make any sense as to why someone would disable an intended feature.
Popup settings aren't neccessarily related the trust level of a zone; a theoretical global setting like 'open popups as tabs' could defeat any attempts to hide the backbutton without directly 'disabling' popups, regardless of the zone; if you can't assume a browser/OS of choice, you certainly can't assume a configuration of choice.
> a theoretical global setting like 'open popups as tabs' could defeat any attempts to hide
> the backbutton without directly 'disabling' popups
You are missing the most important point of this discussion. Users of intranet applications don't try to _get around_ these applications. Suppose you have an intranet application at your work place in which you can check you attendance, your salary slips and all such things related to you, would you still block the popups or try to hack things?
Also if you want to go in nitty gritty details, every action performed on an intranet is almost always logged and monitored. Of course someone who is hell bent on destroying or deliberately hacking the application, there is no stopping it.
I am not saying these things just because I think they should be the way I am saying it, I have seen these things in action, and not one but many. Like I said before, client requirements vary. Would you deny removing the toolbar even whe the client asks for it, yes?
> if you can't assume a browser/OS of choice, you certainly can't assume a configuration of choice.
How about a requirement from client like, "We need this intranet application to work on all OS'es and we don't want to incur extra cost by buying proprietary tools. Oh and please, no custom applications." Plus this what The Web is all about, making applications which run on multiple platforms.
It's not a matter of anyone wanting to get around some protective measure if it's possible for that measure to fail without conscious attempts taken to circumvent it, which in this case it is.
My only point is, there's never really a reason why the back button's function _needs_ to be disabled, and I don't think any client would demand that in a spec, since it's a non-function. If you want to hide the toolbar, you want to hide the toolbar and not only disable the back button, and equally, if you actually want a popup, that's a completely different thing to wanting to disable back. If you want to restrict the user's navigation, you're taking away something a user expects to be able to control without any good reason, and if you want to handle some bug in an application that only occurs when back is pressed; there's something wrong in the application.
I wouldn't deny removing the toolbar in a webpage for a client, infact, I might even deliberately popup and remove the toolbar if it seemed appropriate to do so; but if I was working on an application, I would not make any assumptions about the way the user is going to access it. In short, I wouldn't say 'no I wont throw a popup / remove the toolbar', but I would make sure that the application's actual functionality didn't depend on any page being launched in a popup, in the same way as I wouldn't assume that the pages served by the application will be accessed via Opera9. The fact that an application is or isn't intended to be deployed over an intranet shouldn't really affect design issues at the presentational layer.
That is all. I don't really disagree with you on any point.
If you are using BACK button disabling techniques for an intranet, then also disable bots on your server, so Google won't turn up your page on a search.
www.google.[insert tld] shouldn't be able to find a 'totally' intranet server, since intranets, by definition, are not connected to nor accessible from the Internet, nor subsequently 'the web'. If a certain intranet is accesible (publicly or otherwise) from the Internet, that's OK, and that doesn't make it 'not an intranet', but regardless, no public, or infact any, connection to the Internet is implied.
http://en.wikipedia.org/wiki/Intranet
http://en.wikipedia.org/wiki/Internet
http://en.wikipedia.org/wiki/World_Wide_Web
http://en.wikipedia.org/wiki/Google_search
Read the first paragraph on every page..
Every one here doing only time pass..NO one serious about the issue..The issue is how to disable or restrict the browser back page in ajax enabled page..
Your comment comes a little late.
This thread has been dead for almost three years.
<%
response.setHeader("Pragma","no-cache");
response.setHeader("Cache-Control","no-store");
response.setHeader("Expires","0");
response.setDateHeader("Expires",-1);
%>You cannot disable the back button, but you can redirect to previous page using javascript.
page = new String(history.forward());
if(page="undefined")
{
}
else
{
location.href = history.forward();
}We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.