Material-ui: [TreeView] Unable to use input in TreeItem

[kenianbei]

When embedding an input or textfield in a TreeItem, user is unable to type anything other than space, backspace, delete, but no characters. However pasting does work. Also inputs do work within TreeView, but not TreeItem.

See: https://codesandbox.io/s/long-fire-csg6f?fontsize=14&hidenavigation=1&theme=dark

• [x] The issue is present in the latest release.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

When embedding an input or textfield in a TreeItem, user is unable to type anything other than space, backspace, delete, but no characters. However pasting does work.

Expected Behavior 🤔

We should be able to have inputs or Textfield as children of TreeItem.

Steps to Reproduce 🕹

See: https://codesandbox.io/s/long-fire-csg6f?fontsize=14&hidenavigation=1&theme=dark

Context 🔦

Actually my context is that I have a Dialog within the TreeItem, and when it is opened it is still affected by this issue, since it is still nested within the TreeItem. If it isn't able to be fixed I will move the Dialog outside the TreeItem and use redux state to open the dialog.

Your Environment 🌎

| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.6.1 |
| Material-UI Lab | v4.0.0-alpha.33 |
| React | 16.12.0 |
| Browser | Arch Linux Firefox and Chrome |
| TypeScript | 3.7.2 |
| etc. | |

[kenianbei]

May be related to #17407, however I wasn't able to use the fix from that issue to fix it.

[oliviertassinari]

I don't think that it's a use case we really want to support. However, I guess we could play nicely with it. I see 3 options:

1. We ignore the keyboard event if it comes from an editable field. We have similar logic in https://github.com/mui-org/material-ui/blob/f6a9ea17d64835f9a4180195ae043d02f97601f7/packages/material-ui/src/utils/focusVisible.js#L35-L45.
2. We ignore the keyboard event if event.currentTarget !== event.target.
3. We ignore the problem => won't fix.

@joshwooding Do you have a preference? I'm leaning toward 2.

[eps1lon]

I don't think that it's a use case we really want to support.

I had the same though initially but the problem is (as usual) portals. Having a dialog open from a tree is reasonable IMO.

For keyboard events I'm usually in favor of checking for target === currentTarget.

[oliviertassinari]

Yeah, +1 for not going with option 3 if we want to support:

macOS

Windows

It seems that our best option is number 2.

[eps1lon]

Yeah contentEditable is something that I always forget. Same applies to listitems (e.g. an editable TODO-list).

[joshwooding]

I’m happy with 2. It was the first solution I thought of

[oliviertassinari]

So I guess something like this would do it:

diff --git a/packages/material-ui-lab/src/TreeItem/TreeItem.js b/packages/material-ui-lab/src/TreeItem/TreeItem.js
index ae7be28ae..2066db063 100644
--- a/packages/material-ui-lab/src/TreeItem/TreeItem.js
+++ b/packages/material-ui-lab/src/TreeItem/TreeItem.js
@@ -150,7 +150,7 @@ const TreeItem = React.forwardRef(function TreeItem(props, ref) {
     let flag = false;
     const key = event.key;

-    if (event.altKey || event.ctrlKey || event.metaKey) {
+    if (event.altKey || event.ctrlKey || event.metaKey || event.currentTarget !== event.target) {
       return;
     }
     if (event.shift) {

@kenianbei Do you want to work on a pull request?