[Bug]: unstable_TreeView The L1 retains select state when user collapses and expands L1

[francinelucca]

Package

@carbon/react

Browser

Chrome, Safari, Firefox

Package version

1.6.0

React version

17.0.2

Description

L1 Top levels should not have a select state until an L2 is selected and you happen to collapse the L1. Then it should have the section to indicate an item “inside” that L1 is active.

** Moving this over from carbon-design-system/carbon-platform#1030

Screen.Recording.2022-07-21.at.11.19.15.AM.mov

Reproduction/example

https://stackblitz.com/edit/github-2mpgdk?file=src/App.jsx

Steps to reproduce

1 - Select an L2 using keyboard navigation
2 - Collapse L2 parent using keyboard navigation
3 - Expand L2 parent using keyboard navigation, notice L2 is still visually selected
4 - Collapse L2 parent using mouse click
5 - Expand L2 parent using mouse click, notice L2 is no longer visually selected

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[emyarod]

L1 Top levels should not have a select state until an L2 is selected and you happen to collapse the L1. Then it should have the section to indicate an item “inside” that L1 is active.

I'm not sure if I fully understand the issue but I think this would be application dependent. There are definitely contexts where the selection state of a parent node would need to be separate from selection state of its child nodes (e.g. a file directory like in VS Code or Finder), and changing the parent node behavior to always reflect the selection state of its children would eliminate that

can you provide some more info on what you expect the behavior would be?

[francinelucca]

I'm not sure if I fully understand the issue but I think this would be application dependent. There are definitely contexts where the selection state of a parent node would need to be separate from selection state of its child nodes (e.g. a file directory like in VS Code or Finder), and changing the parent node behavior to always reflect the selection state of its children would eliminate that

If that is the guidance then we can definitely make custom updates on our app, however:

can you provide some more info on what you expect the behavior would be?

I think the case here is we'd expect the keyboard behavior and the mouse behavior to behave similarly; currently the L2 stays active when using a keyboard and doesn't stay active when using a mouse, is this the intended behavior?

[emyarod]

I think the case here is we'd expect the keyboard behavior and the mouse behavior to behave similarly; currently the L2 stays active when using a keyboard and doesn't stay active when using a mouse, is this the intended behavior?

just to clarify, this is only when referring to interacting with the toggle right? like a user can independently toggle the caret with the keyboard without affecting selection, but mouse clicks will always affect selection?

I'll have to think about this one some more because there are cases where mouse clicks are always tied to selection+activation, but there are also examples where they aren't

for example in VS Code, mouse actions always overwrite the current selection state and put selection on the parent node

Screen.Recording.2022-07-28.at.12.03.14.PM.mov

macOS Finder will just erase the selection state completely

Screen.Recording.2022-07-28.at.12.05.47.PM.mov

even though both of these are multiselect trees, I didn't want to completely remove the selection state for a single select context so I went with the VS Code route

I guess a couple options now are:

• changing the default behavior (so that toggle clicks only affect expansion state)
• adding a new config option that can affect this behavior

I would lean towards the first option if we have to make any change at all, but I need to remember if there were any reasons for not going with this approach in the first place. definitely open to more discussion on this topic

[tay1orjones]

I think the case here is we'd expect the keyboard behavior and the mouse behavior to behave similarly; currently the L2 stays active when using a keyboard and doesn't stay active when using a mouse, is this the intended behavior?

Agree, the interaction should be the same between mouse and keyboard

even though both of these are multiselect trees, I didn't want to completely remove the selection state for a single select context so I went with the VS Code route

With this it sounds like the actionable item here is we need to update keyboard interaction to move selection state to the parent when the parent is opened/closed. This would align the keyboard interaction to what happens via click/mouse.