Disabling backspace (back a page) in ajax application

[pebkac]

I've been getting complaints from users who hit backspace outside of a
textbox by accident, and get taken "back" a page by their browser.

In our AJAX application this is really annoying, as it takes them back
to the "login" page, and they have lost everything they were doing.

Is there a simple way to disable this using javascript? I've tried
trapping the unload event, but this doesn't seem to fire in the case of
the backspace/back action.

Any ideas greatly appreciated

PK

 

[David Mark]

I've been getting complaints from users who hit backspace outside of a
textbox by accident, and get taken "back" a page by their browser.

That's what browsers do.

In our AJAX application this is really annoying, as it takes them back
to the "login" page, and they have lost everything they were doing.

That's due to a poor design (typical of such applications).

Is there a simple way to disable this using javascript? I've tried
trapping the unload event, but this doesn't seem to fire in the case of
the backspace/back action.

Any ideas greatly appreciated

Don't disable built-in navigation under any circumstances. If your
application works with fast history navigation (which is disabled by
using an unload listener), then the user can simply go forward and
return to the state they were in before they left. Of course, some
browsers (e.g. IE) lack this feature (or at least implement it in a
way that destroys the DOM state), so if you want to solve this for all
users, you need to look into persisting the application state yourself
(e.g. with cookies or localStorage).

 

[David Mark]

On 17/07/10 17:11, pebkac wrote:

What a fitting nickname for this problem ;-)




onunload is too late; use onbeforeunload.

Yes, if the application is some sort of editor, then confirming
whether they want to abandon their changes is a good idea.

 

[Garrett Smith]

That's what browsers do.

That is what IE did and what other browsers copied but that behavior can
be configured by some browsers. For example, in Firefox, setting
`browser.backspace_action` to -1 will stop that.

http://kb.mozillazine.org/Browser.backspace_action#Possible_values_and_their_effects

[...]

It may be worth mentioning this to the user, so that the user can
reconfigure his browser to avoid the undesirable user experience.

Don't disable built-in navigation under any circumstances. If your
application works with fast history navigation (which is disabled by
using an unload listener), then the user can simply go forward and
return to the state they were in before they left. Of course, some
browsers (e.g. IE) lack this feature (or at least implement it in a
way that destroys the DOM state), so if you want to solve this for all
users, you need to look into persisting the application state yourself
(e.g. with cookies or localStorage).

There are other considerations that can be made where javascript is
enabled in the user's browser.

An alternative is to add onbeforeunload event handler, where that is
supported. In the callback, user can be warned if he has a dirty page.
"Dirty page" means that the state has changed but the changes have not
been posted (saved) yet.

The onbeforeunload event is widely enough supported now that it should
cover a good number of browsers. For example:

// Localized messages generated from .properties files.
var pageMessages = {
CANCEL_UNLOAD : "Would you like to discard unsaved changes?"
};

window.onbeforeunload = function(ev) {
ev.returnValue = pageMessages.CANCEL_UNLOAD;
};

If the user decides to choose the "cancel" option in the
`onbeforeunload` dialog, then the page will not be navigated away from.
Keep in mind that the actual button text and message "OK"/"cancel" will
vary depending on the browser and the language settings.

See also:
<http://jibbering.com/faq/#changeBrowserDialog>

"Dirty page" state can additionally be displayed in the application. For
example, if the user blurs an input, then an update icon (spinner.gif)
can show that the data is being updated and when this goes away, then it
is clear to the user that data has been saved.

Such U/X is not going to be sufficient where the user may carefully edit
input over a period of time (suchas TEXTAREA, CANVAS). In that case, the
interface needs some sort of "Save" button. That "Save" button can be
enabled upon user changes and disabled upon successful save. If the
button is disabled on a request to make a save, then the possibility of
the request failing must be accounted for because that request will fail
under conditions that are uncontrollable to the program. If the button
is disabled when the user clicks "Save", then it must be reenabled when
the request fails and that request failure must be tested.

A few cases where a user request can fail (if they are not obvious) are
when the HTTP request does not reach the server (perhaps the user has
lost his wireless connection) or the HTTP request reaches the server but
the server-side program cannot process the request (the server itself is
down, the program is too busy, etc).

The user clicking "Save" is only a request to save, it does not mean
anything has been saved.

 

[David Mark]

That's what browsers do.

That is what IE did and what other browsers copied but that behavior can
be configured by some browsers. For example, in Firefox, setting
`browser.backspace_action` to -1 will stop that.

http://kb.mozillazine.org/Browser.backspace_action#Possible_values_an...

[...]

It may be worth mentioning this to the user, so that the user can
reconfigure his browser to avoid the undesirable user experience.

Yes, but the OP also seemed unhappy with navigation by other means
(e.g. the back button), which also caused the application to lose its
state.

There are other considerations that can be made where javascript is
enabled in the user's browser.

An alternative is to add onbeforeunload event handler, where that is
supported. In the callback, user can be warned if he has a dirty page.
"Dirty page" means that the state has changed but the changes have not
been posted (saved) yet.

Yes, as mentioned in a follow-up, if the application is an editor of
some sort (and not just looking to preserve the UI state).

 

[David Mark]

http://tinyurl.com/23bastf

Um, we're trying to have a civilization here. The example has a
comment at the bottom that indicates what a bad idea it is.

"It works in IE7 and Firefox3.0."

That should tell you something.

<script language="JavaScript1.2">

Never use code from an example that features a language attribute.

// Every single key press action will call this function.

That's not what it does.

function shouldCancelBackspace(e) {
var key;
if(e){
key = e.which? e.which : e.keyCode;
if(key == null ¦¦ ( key != 8 && key != 13)){ // return when thekey is
not backspace key.

On what planet would 13 indicate a backspace?

return false;
}
}else{
return false;
}

if (e.srcElement) { // in IE
tag = e.srcElement.tagName.toUpperCase();
type = e.srcElement.type;
readOnly =e.srcElement.readOnly;
if( type == null){ // Type is null means the mouse focus on a non-form
field. Disable backspace button

No it doesn't.

[snip more fantasy code]

// check the browser type

Discard on sight.

function whichBrs() {
var agt=navigator.userAgent.toLowerCase();
if (agt.indexOf("opera") != -1) return 'Opera';
if (agt.indexOf("staroffice") != -1) return 'Star Office';
if (agt.indexOf("webtv") != -1) return 'WebTV';
if (agt.indexOf("beonex") != -1) return 'Beonex';
if (agt.indexOf("chimera") != -1) return 'Chimera';
if (agt.indexOf("netpositive") != -1) return 'NetPositive';
if (agt.indexOf("phoenix") != -1) return 'Phoenix';
if (agt.indexOf("firefox") != -1) return 'Firefox';
if (agt.indexOf("safari") != -1) return 'Safari';
if (agt.indexOf("skipstone") != -1) return 'SkipStone';
if (agt.indexOf("msie") != -1) return 'Internet Explorer';
if (agt.indexOf("netscape") != -1) return 'Netscape';
if (agt.indexOf("mozilla/5.0") != -1) return 'Mozilla';

if (agt.indexOf('\/') != -1) {
if (agt.substr(0,agt.indexOf('\/')) != 'mozilla') {
return navigator.userAgent.substr(0,agt.indexOf('\/'));
}else
return 'Netscape';
}else if (agt.indexOf(' ') != -1)
return navigator.userAgent.substr(0,agt.indexOf(' '));
else
return navigator.userAgent;
}

// Global events (every key press)

var browser = whichBrs();
if(browser == 'Internet Explorer'){
document.onkeydown = function() { return !
shouldCancelBackspace(event); }
}else if(browser == 'Firefox'){
document.onkeypress = function(e) { return !
shouldCancelBackspace(e); }
}

</script>

Observe, copy, paste, publish, perish. Repeat as needed (usually
forever). This is how most libraries are done.