[Bug]: When dragging <TreeItemLayout>, the content on top of it is also included in the dragging shadow

[chenxinyanc]

Library

React Components / v9 (@fluentui/react-components)

System Info

"@fluentui/react-components": "^9.30.3"

(Using CodeSandbox)

Are you reporting Accessibility issue?

no

Reproduction

https://codesandbox.io/s/draggable-tree-items-xskd6w?file=/example.tsx

Bug Description

Actual Behavior

If the TreeItemLayout has actions prop set, when it gets dragged, not only is the tree item itself rendered in the dragging shadow, but ALL THE CONTENT on top of the tree item is also rendered. This is wierd.

Expected Behavior

On the other hand, if the TreeItemLayout does not have actions, the dragging shadow behaves correctly.

Logs

No response

Requested priority

Normal

Products/sites affected

No response

Are you willing to submit a PR to fix?

no

Validations

• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[TristanWatanabe]

Can confirm that this is a bug - when a TreeItemLayout has actions and draggable props set, whenever a drag attempt is made, elements above appears to get dragged as well.

https://github.com/microsoft/fluentui/assets/8649804/3c99c105-5830-4bd5-bdee-45aa4539801b

[jurokapsiar]

I would not recommend using just draggable to achieve drag and drop. Browser does not provide all features necessary to make the interaction accessible.

Please see https://react.fluentui.dev/?path=/docs/components-tree--default#drag-and-drop for an example showing how to integrate Tree with full featured drag and drop library.

[chenxinyanc]

I would not recommend using just draggable to achieve drag and drop. Browser does not provide all features necessary to make the interaction accessible.

I understand. However, we are currently collaborating with partner teams so we can drag tree item into their component rectangles.

Since they are packing their dependencies into a self-contained & stand-alone package, it would be rather tricky to let them adopt any additional (and some specific) drag 'n' drop library because

1. they are not using the same library,
2. due to how they are packing their dependencies, we will result in having 2 duplicate package instances that we are not sure whether they can work together stably.

I also understand their are many UX/accessibility gaps in the current browser implementations, and my justification might not be strong enough, but I do hope we keep this issue open before figuring out what has happened to the browser. (Firefox does not have such issue.)

[bsunderhus]

Ok, I've narrowed this down to a possible tabster problem. Here's the same example reproduction but manually opting out of tabster. I'm not sure how is it possible that tabster influences this behaviour

[microsoft-github-policy-service[bot]]

This issue has not had activity for over 180 days! We're adding Soft close label and will close it soon for house-keeping purposes. Still require assistance? Please add comment - "keep open".