I am trying to set an edit box on an XPage so that, when a user presses the Enter key, the form will not be submitted, but something else will happen instead. I have javascript code that works for this purpose on legacy Domino forms, but seems to be broken on XPages.
For testing, I have a function in a client JS library called “isEnterKey” which returns true if called when the Enter key is pressed, false otherwise.
I have this simple code in the onkeypress event of an edit box:
if (isEnterKey(thisEvent)) {
alert(‘Enter key!’);
return false;
} else return true;
When tested, it is correctly showing the alert “Enter key!” when (and only when) I press the Enter key in that edit box, but the form is still being submitted. How can I stop the form submission?
Subject: Does ‘No Data Validation’ help?
have you tried adding ‘No Data Validation’ to the event as a first step?
Subject: ‘No data validation’ makes no difference
I set “No data validation” for the onkeypress event, where I first put my client-side code, and it made no difference.
For completeness, I’ve also tried adding client-side code for both the onkeydown and onkeyup events just saying “return false”, and have also set “No data validation” on those events.
It makes no difference. Pressing the Enter key in this field still seems to submit the page.
Subject: Pressing Enter on a Edit box shouldn’t submit the XPage anyway?
Unless there is a action triggered by some event in the edit box
Subject: The submission is not caused by an event; it’s default browser behaviour
Some browsers, by default, submit forms when the Enter key is pressed in a text field. According to one website I’ve checked, this occurs when there is only one text field on the form, and does not occur otherwise.
This submission can normally be stopped by having an onkeypress event return false. See the example on the bottom half of this page: http://jennifermadden.com/javascript/stringEnterKeyDetector.html
This works in a legacy Domino form, but does not work in XPages.
I did some experiments with this today, and I’m now fairly sure that the cause is the way the XPage auto-generated client JS attaches events to elements. If I use the XPage designer to write an event that returns false, it seems like the return value is caught somewhere in the XSP object, but is not passed back to the element that triggered the event. Therefore, the browser still treats the event as if it returned true, and the default submission still occurs.
I have managed to work around the problem by avoiding the XPage designer for the onkeypress event. Instead, I’ve written code in a client JS library to find the text field and attach my own event, which does not use the global XSP object at all. This works, but was more difficult to code.
Subject: SOLVED: use “thisEvent.preventDefault()”
I had a brainwave this morning: XPage client-side JS uses Dojo, so documentation on the Dojo website might relate to the global XSP object in XPages.
On the Dojo website, I found that Dojo events use a special event class, which contains a method called “preventDefault”.
My onkeypress event now looks like this:
if (thisEvent.keyCode==13) {
thisEvent.preventDefault();
// And some other code for an alternative action...
}
Wonder of wonders, pressing Enter in that field no longer submits the form.