Native dragstart never fires when a modifier key (e.g. Shift) is already held down before the drag gesture starts

[yevhen330]

Describe the bug
If Shift (or another modifier key) is already held down before the mouse button is pressed to start dragging a tree item, the native HTML5 dragstart event never fires at all - the drag simply never begins. This happens with items rendered through renderItem, using context.itemContainerWithoutChildrenProps / context.interactiveElementProps (the library's own native drag wiring - draggable + onDragStart from createInteractiveElementProps), no external DnD library involved.

If the drag is started without Shift held (mouse down, move a bit) and Shift is only pressed after the drag has already begun, everything works as expected - the drag continues and dragover/drop correctly see shiftKey: true.

Confirmed via Chrome DevTools "Event Listener Breakpoints -> Drag -> dragstart": the breakpoint never pauses when Shift is held from the start of the gesture, but does pause for a normal (no-modifier) drag.

To Reproduce
Steps to reproduce the behavior (using the official Storybook, no external DnD library):

Step 1: Open https://rct.lukasbach.com/storybook/?path=/story/core-custom-renderers--minimal-renderers
Step 2: Press and hold Shift.
Step 3: While still holding Shift, press the mouse button down on any tree item and try to drag it.
Step 4: Nothing happens - no drag preview, no drop indicators, dragstart never fires.
Step 5: For comparison - release Shift and repeat steps 3-4 without it held; dragging works normally. Or: start the drag without Shift, then press Shift mid-drag; this also works fine (drag continues, doesn't restart).

Expected behavior
Dragging should start the same way regardless of whether a modifier key happens to already be held down at the moment the gesture begins.

Additional context
We have the exact same symptom in our own app for a tree built with ControlledTreeEnvironment + a custom renderItem, which made us initially suspect our own drag implementation. However, the Storybook example above - which uses react-complex-tree's own native drag-and-drop, no external DnD library involved - reproduces the identical behavior, which points to this being a react-complex-tree issue rather than something specific to a consuming app's renderItem/DnD setup.

We spent a while ruling out other explanations before landing here: it's not native browser text-selection stealing the gesture (no selection is ever created), it reproduces across browsers/incognito (not an extension or OS-level modifier feature), and it's not caused by useHotkey's partial-combo-match preventDefault() on bare modifier keydowns (we patched that locally and the symptom was unchanged). At this point the most likely remaining explanation is something in how draggable/onDragStart get wired up through renderItem's interactiveElementProps, but we haven't pinned down the exact mechanism.

• OS: macOS
• Browser: Chrome (also reproduces in other browsers)
• Version: 2.6.0

[lukasbach]

Hi, thanks for the report!

I believe this is apparently caused by renderItemTitle rendering span elements inside the surrounding button element. I'm not sure why the browser handles drag events differently when a button contains span elements, but changing renderItemTitle to just return simple text seems to not trigger this behavior. I've updated the sample storybook that triggers this issue to remove the span element there.