0053404: Non-homogeneous behaviour of the ENTER and ESC keys in forms and popups components.

Description

There are many components that have forms and when pressing the ENTER and ESC keys nothing seems to happen.

Steps To Reproduce

When using the requestInputData or the requestConfirmation elements, it happens that when a text input is requested from the user (for example using the Payments API, with the payment method configured to use Payment API, in POS2: menu -> Till -> Payment Terminal -> autotest). However, you may have noticed that when you press the Enter key, nothing seems to happen. This behavior might seem inconsistent or confusing, especially if you're used to different forms in various applications.

This can be reproduced in many components, for example in the Adyen module when the configuration is set to ask the barcode scanner, when scanning the barcode, an ENTER is sent by the scanner and it's meant to submit the code and continue the payment processing, but nothing happens.

Proposed Solution

I suggest that there should be a homogeneous behaviour for the popups and forms. This is a general overview of their typical behaviours:

Popups:

- Enter: Usually, the Enter key will activate the primary action of the popup. For instance, if the popup is asking the user for confirmation to delete something, pressing Enter might be equivalent to clicking the "OK" or "Delete" button.
- ESC: Typically closes the popup or dialog without taking any action (akin to clicking a "Cancel" or "Close" button).

Forms inside popups:

- Enter: Submitting the form is the most common action associated with the Enter key in the context of a form. This could mean sending data, saving a post, logging in, etc., depending on the specific form's purpose. Note that this is already implemented in some Openbravo components, such as the Login form, hence the insistence on consistency of behaviour. However, there's an exception: in multi-line text input fields (like a textarea), Enter usually navigates to the next line rather than submitting the form. This can be reproduced in the Payment API by sending a STRING message type with multiple input values.

Issue History
Date Modified	Username	Field	Change
2023-09-06 16:22	ignacio_deandres	New Issue
2023-09-06 16:22	ignacio_deandres	Assigned To	=> Retail
2023-09-06 16:22	ignacio_deandres	Triggers an Emergency Pack	=> No
2023-09-06 16:24	ignacio_deandres	Assigned To	Retail =>
2023-09-07 08:47	ignacio_deandres	Steps to Reproduce Updated	View Revisions

Relationships [ Relation Graph ] [ Dependency Graph ]