Skip to end of metadata
Go to start of metadata


The purpose of this functionality is to allow configuration in the UIF for enter key behavior.



All components will have a new property for configuring the enter key action.


String enterKeyActionId - Id of the action that should be triggered when the enter key (key up) event is triggered on the component.


String addLineEnterKeyActionId - Id of the action that should be triggered when the enter key if invoked on a field in the add line (note if the enter key is specified for a zone in the line it will override).

String lineEnterKeyActionId - Id of the action that should be triggered when the enter key if invoked on a field within an existing collection line (note if the enter key is specified for a zone in the line it will override).


Each component with a configured enter key action creates a zone. When the enter key event occurs on the view, its zone will be found to determine what action should be invoked. This zone if found by finding the nearest ancestor element that has a configured enter key action.


Element Zones

In the above example, if focus is on the input field with name travelerFirstName, travelerLastName, or the button with id 'details', the action (button) with id 'details' will be triggered. When focus is anywhere outside these elements, the action (button) with id 'save' will be triggered.

There is no limit to the zone nesting level.


Example 1
Example 2

For triggering custom script or other actions on the enter key, add custom script for the key events.



  1. Should we set any defaults? What about actions that are part of collection lines (like the add or delete buttons)?
  2. When focus is on an action (button, link, image), or link, should the default enter key action be to trigger that action and ignore zones (this is default browser behavior for most actions and links, although inputs of type image seem to not get triggered)?
  3. What accessibility concerns need to be addressed? My assumption is this functionality would have no impact on AT devices.

Implementation Notes

  • Data attribute "enterKey" would be added to the component for the enterKeyActionId specified on the component
  • On the client we are going to look for an enterKey attribute on the component itself,and invoke that action by triggering a click event on that link or button.
  • If set on an action, do not add the enterKey data attribute, possibly throw an exception
  • krad.initialize.js for the elements that have data attribute enterKey we add a keyup event handler to them, which will catch child events, when enter is the key event caught, invoke above logic and stop propagation of the event
  • For collection groups we are going to have to add rowDataAttributes that get output on the tr in the table collection case and output on the group of the stacked collection item in the stacked collection case
  • Adding a special value for enter key ids called "@PRIMARY" that will invoke the primary button of that group, but primary buttons must be identified by the primaryAction boolean flag which will add a data attribute called "primary_action" and set that true.   This will be targeted instead of an explicit id in this scenario.
  • In stacked group scenario add the enterkey data attribute to the stackedGroups that are added in build line
  • Read through this, good read to understand our approach
  • primary and id work work slightly differently, primary is just looking for the jQuery :first selection with primary flag it finds in that group and id is globally
  • only fire the action click event if the action is not disabled and not hidden




  • No labels


  1. Concerning the issues outlined above:

    1. Defaults: If defaults are set, the default for a zone should be the action that the user is most likely (in most cases) to take within that zone to save/complete/continue with available options.  A default should be on an action that would not cause the user to lose data (so never default to delete, remove, etc. - if the user wants to do those actions, they should tab to that action and then hit enter).  Also, the default action should logically follow whatever task is provided within the zone (for example, if a user hits the enter key from within a search field, the search is initiated). A default setting should never lead the user to take an optional/unlikely action within their workflow.  In the example provided above, the user enters their first and last names in different fields and the enter key initiates the details screen - this would not be an expected action.  The details screen represents an optional path the user might want to take and is a good example of what NOT to set for a default. Happy to discuss in person if any of this does not make sense.  Ultimately, on the back end, structuring as you suggest above makes sense - there will just need to be some standards and guidelines for implementing within a system context so that it makes sense to the user and their normal workflow.
    2. Focus on an action item:  Yes - if the focus is on a specific button/item, hitting the return key should trigger the action associated with that button.
    3. Accessibility: I'll see what I can find out about the accessibility concerns and get back to you on that one.
    1. Thanks Tara!

      It sounds like on the defaults, it will be hard for the framework to do anything (since the framework can't determine which action should be the default for a zone or if the action is destructive). The developer can set the action based on the design. The only situation I can think of where we provide a button and know what it does is the add button on the add line, would this be a reasonable default or should we just require the developer specify it?


  2. Agreed - It would be hard for you to set up defaults within the framework given context is going to dictate what makes sense.  The framework just needs to provide the ability for the developer to set the defaults.  For the add line, if the user is within that line/zone and clicks enter - that would be an appropriate default and the developer could disable or set to something else if the context warranted it.