Input component in modal dialog cannot be cleared using `esc` because `esc` closes the modal.

[etait127]

Check existing issues

• [X] I have checked for existing issues to avoid duplicates

Summary

The standard way to clear a calcite input field is to use esc. However, if you have an input field in a modal dialog esc closes the modal dialog.

Actual Behavior

Input fields in modal dialogs cannot be cleared using the keyboard. The standard esc pattern used by calcite input fields elsewhere does not work in the case of the modal dialog because esc closes the modal.

Expected Behavior

esc should consistently clear the input field in all use cases, OR the x clear button that appears in the input field when you start typing should be keyboard accessible

Reproduction Sample

https://codesandbox.io/s/calcite-a11y-input-clear-bug-yvn23s?file=/src/App.js

Reproduction Steps

1. open modal
2. type into input field
3. hit escape to clear the input field <- observe that the modal just closes

Reproduction Version

1.10

Working W3C Example/Tutorial

No response

Relevant Info

No response

Regression?

No response

Priority impact

p4 - not time sensitive

Calcite package

• [ ] @esri/calcite-components
• [X] @esri/calcite-components-react
• [ ] @esri/calcite-design-tokens
• [ ] @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Knowledge

[macandcheese]

The provided sample is using a non-Calcite Modal. When used in a Calcite Modal, the behavior you mention should not occur.

HOWEVER! There is an oddity we might want to fix (or determine it is expected, and not fix it).

• When the input is within a Modal, has focus, and has no populated Value (so the clearable button IS NOT visible), Escape press WILL close the Modal.
• When the input is within a Modal, has focus, and HAS a populated Value (so the clearable button IS visible) Escape press WILL NOT close the Modal, but will successfully clear the Input. Then, it reverts back to the above case, and a subsequent key press will close.

cc @ashetland @SkyeSeitz for design and @geospatialem for a11y thoughts.

[geospatialem]

HOWEVER! There is an oddity we might want to fix (or determine it is expected, and not fix it).

For the a11y perspective: We should follow native HTML, where the esc key always closes the modal regardless of components housed inside the component.

If a native input is added to a modal, even when it is clearable (when set as <input type="search" />) the dialog will close. We should allow the esc key outside of the modal dialog, but it should not supersede the modal's intent with the esc key.

@macandcheese Depending on the design perspective, would recommend we repurpose this issue to remove the esc functionality for calcite-input to not supersede calcite-modal's ~and calcite-popover's~* functionality with esc.

*_Update: popover seems to be fine as-is._**

[macandcheese]

From an end-user perspective that does seem unexpected, since the focused element may be involve another functionality that uses the Escape key, not just this Input clearable example.

For example, if a user was in an editable content area with "save" and "clear" functionality - in that case it would be recommended to close the containing Modal on "Escape" even though a user is engaged in a more micro-level workflow within?

We do have some other places where we have this "nicety" of not closing an open parent (Shell Panel or Panel if I remember) - I think that would be a negative for usability if this is removed in those places as well. I guess I feel similarly about Modal, but, I wonder if there are other examples w3 provides that have more rich content.

[geospatialem]

but, I wonder if there are other examples w3 provides that have more rich content.

There is one on the same page under the example section showcasing input's with addresses in a modal dialog, where both an input with type of "text" and "search" behaves in the same manner.

[ashetland]

I think even in that example the workflow is pretty simple. Each input only accepts text entry with no way to clear them without manually deleting the entry. In that example it is pretty clear to me that pressing esc would result in closing the modal, but I agree that with a seemingly simple workflow addition of clearable inputs, I'd expect esc to clear the focused input first, then upon a second esc close the modal. Suggest more research is needed on this.

[driskull]

What should happen is...

If the escape key has default prevented on the input, the modal should not close

Basically, the modal should check if the event is prevented before closing. It looks like its already doing this. So I think this issue is invalid?

[geospatialem]

This can be achieved by preventing the close event on the host modal when pressing the esc key and when the input has focus: https://codepen.io/geospatialem/pen/PovJNdO

With MUI, the disableEscapeKeyDown property could be toggled when calcite-input is in focus, so the modal remains open and the content can be cleared from the input.

A documentation snippet will be added in a future milestone with additional context for developers to implement.

[DitwanP]

After looking into this, it seems like the expected behavior of clearing the focused input with esc and then closing the modal with another press of esc is already working as intended in Calcite as @macandcheese mentioned above. Example

It was also mentioned above that the original repro was not using a Calcite modal. Although we don't have any control over how that works, the comment that Kitty left above provides an alternative solution for such use cases. (Manually preventing any modal from closing when nested input is focused).

Closing this out as there isn't anything that needs to be done on our end.