Prev: How to find if statusbar is hidden or visible in firefox?
Next: [ANN] Call for Participation for 2010 Workshop on Scheme and Functional Programming
From: pebkac on 17 Jul 2010 11:11

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

From: Stefan Weiss on 17 Jul 2010 12:44
On 17/07/10 17:11, pebkac wrote:

What a fitting nickname for this problem ;-)

> 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.

onunload is too late; use onbeforeunload.

You probably won't catch all cases with this. Since it's an "Ajax
application", the server should be able to know the exact state of the
page. When a user does navigate back to the login page, you can
recognize that he's already logged in and display the application page
instead. Use whatever information you have on the server about the last
state to initialize the page. You may need to discourage client side
caching on the login page for this to work.


--
stefan
From: David Mark on 17 Jul 2010 15:48
On Jul 17, 11:11 am, pebkac wrote:
> 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).
From: David Mark on 17 Jul 2010 15:51
On Jul 17, 12:44 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
> On 17/07/10 17:11, pebkac wrote:
>
> What a fitting nickname for this problem ;-)
>
> > 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.
>
> 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.
From: Garrett Smith on 17 Jul 2010 18:55
On 2010-07-17 12:48 PM, David Mark wrote:
> On Jul 17, 11:11 am, pebkac wrote:
>> 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.
>

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.

>>
>> 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).

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.
--
Garrett
 |  Next  |  Last
Pages: 1 2
Prev: How to find if statusbar is hidden or visible in firefox?
Next: [ANN] Call for Participation for 2010 Workshop on Scheme and Functional Programming