Forum Stats

  • 3,816,401 Users
  • 2,259,184 Discussions


ENTER Key in Editable Form Table Exits Edit Mode

DaveArch Member Posts: 117 Red Ribbon

JET Version: 10.0

Hi JET Community

We are using the Editable Form Table pattern and have some challenges with the way in which using the ENTER key on a keyboard exits the edit mode for the row.

The problem arises where the ENTER key is integral to the functionality of a component but using it in this pattern exits edit mode and does not have the desired effect on the component. There are 2 issues specifically:

1) Cancel Button: Using the same pattern as in the Cookbook demo, if you edit a row, navigate to the Cancel button and hit the ENTER key, edit mode is exited and the data is committed to the table. This is because the function on the button call (handleCancel) isn’t called because the table has stolen focus and the button action is not fired. You can see this on the Cookbook Demo. This is quite fundamental because if a keyboard user edits a row and actions the Cancel button with the ENTER key they would expect the change to be cancelled when actually it is committed to the table. You can get around this using the space bar to action the buttons however users more instinctively use ENTER and the JS Doc states that both ENTER and Space can be used.

2) Text-Area: When using a OJ <text-area> within an Editable Form Table, users will often need to use the ENTER key to create new lines however this is not possible as the table exits edit mode when the ENTER key is used. You can get around this by using ALT+ENTER however this is unintuitive and users are struggling with this.

Is anyone able to provide a workaround for these features?

I was thinking whether it is possible to intercept the event to cancel the default behaviour and to not exit edit mode under certain conditions?

Many thanks

Best Answer


  • DaveArch
    DaveArch Member Posts: 117 Red Ribbon

    Bump - any ideas on this from the Oracle guys?

    This is causing our users with accessibility needs a fair bit of grief as they are hitting ENTER on the Cancel button and it's committing the changes to the table.

  • John 'JB' Brock-Oracle
    John 'JB' Brock-Oracle Posts: 2,776 Employee
    Answer ✓

    You will want to take a look at the on-oj-before-edit-end event. Handle any conditions that you need in there and either preventDefault to stop the editing from ending, or let it continue.

  • DaveArch
    DaveArch Member Posts: 117 Red Ribbon

    Thanks John.

    I assume you mean ‘on-oj-before-row-edit-end’ event as I couldn’t find ‘on-oj-before-edit-end’.

    Unfortunately, it is still very difficult to get around this problem by using this function. If a user hits the spacebar when focus is on an <oj-button>, everything works as expected i.e. the button function is called before the function attached to on-oj-before-row-edit-end.

    The problem is with the ENTER key, as described above. In this case, the table steals the event first and closes the editable region and the function attached to the button is not fired.

    it is easy to identify the escape key via event.detail.cancelEdit but it is very difficult to identify any button action executed via the ENTER key.

    Below is the workaround we used to get around this should anyone else hit this issue. With the introduction of asynchronous support in edit table forms in later JET releases, I suspect this issue can be more easily dealt with.


    <oj-table on-oj-before-row-edit-end='[[beforeRowEditEndListener]]' …>
    <!-- In Editable Form Table region -->
    <oj-button :id="[[myokbutton]]" ...>

    View Model (with some debugging): 

    this.okButtonId = "myokbutton"; // Bound to id attribute of Ok button in Editable Form table
    self.beforeRowEditEndListener = (event) => {
        /* Logic to try and determine whether function is called by
          button press on one of the toolbar buttons. Very difficult
          because if using click/touch, the function on the button
          fires before this function whereas with an ENTER keyboard event,
          the button function does not fire at all unless this function
          calls event.preventDefault(). Therefore, the only way to detect
          whether a particular button has been toggled by the ENTER key
          is to inspect the event itself (originalEvent.path). It is
          pretty horrible but seems to work. Therefore this logic checks
          to see if either the Ok button has been toggled with
          ENTER and if so, it issues event.preventDefault() */
        if (event.detail && event.detail.originalEvent) {
         if (event.detail.originalEvent.keyCode) {
          let keyPressKeyCode = event.detail.originalEvent.keyCode;
          if (keyPressKeyCode == 13) {
           console.log("beforeRowEditEndListener(). ENTER key selected in edit row region. Checking for button selected")
           let path = event.detail.originalEvent.path;
           if (path) {
            // Search for the id of the ok button in the path
            let okButton = path.filter(obj => { return == this.okButtonId });
            if (okButton && okButton[0]) {
             console.log("beforeRowEditEndListener(). Button is edit row region OK button hit with ENTER key. Canceling default event.");
            } else {
             console.log("beforeRowEditEndListener(). Button is not edit row region OK button");
        // Other logic to process row change here
  • Hi Dave, try adding this attribute to the oj-button


  • DaveArch
    DaveArch Member Posts: 117 Red Ribbon

    Thanks John, we tried data-oj-clickthrough="disabled" and this didn't work either, the table still stole the focus early and exited edit mode.

  • Ok, one other thing that has tripped me up in the past with something like this. Are you using the oj-oj-action attribute for the oj-button click?

    If so, the event.preventDefault() that you are calling, is going to prevent the onojAction event from defaulting, but it won't do anything for the lower level "click" event. Try using event.detail.originalEvent.preventDefault()

  • DaveArch
    DaveArch Member Posts: 117 Red Ribbon

    There is a function bound to on-oj-action.

    We actually need this to fire though as this function sets a variable which is then checked in the on-oj-before-row-edit-end to see whether the user has positively confirmed the changes as opposed to navigating away from the region via a click/blur event.

    Therefore, with the workaround we have defined, the event flow is as follows:

    • User navigates to button via keyboard and hits ENTER key.
    • on-oj-before-row-edit-end function fires and workaround detects ENTER key calling event.preventDefault()
    • oj-oj-action function fires and sets variable used to detect Ok button action
    • on-oj-before-row-edit-end function fires again, checks variable and commits change to data provider.

    It's useful to know that for future reference though.

    Many thanks.

  • DaveArch
    DaveArch Member Posts: 117 Red Ribbon we just need to find a workaround for oj-text-area and the ENTER key as originally described. Currently the user needs to use Alt+ENTER which is not intuitive.