Backspace key and FormItems

[amcculley]

Our app has an odd bug where if the user holds down the backspace key (for instance - when deleting a long string), the browser will rarely but occasionally go back... as if the user clicked the back button on the browser.

My question is.... how can I try to intercept the Backspace key? I know it may / may not work for all browsers but that is fine.

I've searched up and down and can't find a reliable solution.

Page.setEvent() isn't a valid API call so I can't do it there.

Page.registerKey() doesn't work because it doesn't have anything to do with events so I can't cancel an event before it reaches the browser. This just seems to be a hook for doing something on a keypress but without being able to cancel the event, the browser still gets the keypress eventually.

FormItems don't have a setDefaultProperties() API call so I'm unable to add a keyPressHandler to all FormItems by default. This means this eventhandler would have to manually be added to every TextItem or TextAreaItem manually - not really a viable solution at this point.

DynamicForm has addItemKeyPressHandler which almost gets us there. The problem is, canceling the event there also cancels it for the FormItem itself... despite the docs appearing to me that it would not. It seems like the wording does exactly what I need... allows the FormItem to process the event and then bubble it up to the Form itself where I can cancel it.

Thoughts?

[Isomorphic]

Cancelling keyboard events won't really work that way - by natively cancelling the event at any level in the DOM this will suppress the native behavior (of modifying the form item value).
Moreover, it's unlikely that this approach will solve this issue - most likely this is some kind of native browser bug whereby focus is shifted from the form item into some other element (perhaps due to a redraw coinciding with a keypress or similar), at which point the browser processes the backspace with its default behavior of navigating the previous page.

It'd probably be best if you can show us a way to reproduce this (IE a test case we can run) along with full environment details (browser, OS etc), steps to reproduce and an idea of the frequency with which you're able to trip the bug.

Note - we're assuming this issue is coming up in the app running in deployment mode. If it's development mode only it may be simply a GWT plugin oddity in which case there is unlikely to be anything we can do (and it would not effect end users in this case anyway)

Regards
Isomorphic Software

[rbhuta]

Hi,

I am able to re-produce this issue consistently.

Use case :
1. Create a Form containing text items.
2. Set the canEdit property to false at the form level , not at field level.
3. In either the development or compiled mode. Click on the text item to focus the cursor on this item.
4. The cursor is now in the text item as if it was editable. (Tough you wont be able to edit the value in this field)
5. Press backspace and the browser will go back to the previous page.

Enviornment :
SmartClient Version: v8.2p_2012-05-30
IE: 8.0
OS: Windows XP Professional

Regards,
Ravi.

[Isomorphic]

Hi Rbhuta,
We've made a change to both the 8.2p and 8.3d branches to address this issue. It should be present in nightly builds going forward (July 14 and greater).

Regards
Isomorphic Software

[rbhuta]

Thanks Isomorphic.