Detecting control or alt key during onDrop

[jospvl]

When monitoring for an onDrop event, I want to detect if the user has held down the control key or alt key to determine if a move or copy should occur. However, it seems that the onDrop event is cancelled on this occasion and dragend is fired instead. The dropTargets array is also empty. Why is this happening and is it at all possible to allow users to do a drop with the control or alt key down?
The input structure seems to suggest this, as it holds attributes for these keys as well as meta and shift, but in practice, only the shift key will result in a successful drop.

I noted that in the dragend listener in lifecycle-manager, state.current does show the attributes for ctrlKey and the others to be set to true, but this gets overwritten by the input from the event, where these attributes are false, even if the respective keys are held down.

[jospvl]

You can see this happening in the List example:

• start dragging a list item
• press and hold the control key
• drop the item between two others
  Result: the drop is not performed.
  Doing the same with the shift key works fine.

[evanheckert]

It's great that they made this repo. Bummer that they ignore it. I'm not able to start dragging while holding the shift key, with no clear way to override this behavior.

[rakurtz]

I encountered something similar. I guess especially shift, strg and alt or control keys in combination with mouse controls are used by the system. i also wanted to use the shift key but implemented the wanted behaviour with the pressing of the "c" key instead. works flawlessly.

Example for a "copy" mode when drag and drop elements.

 // local state
  const [isDragging, setIsDragging] = useState(false);
  const keyStates = useKeyPress(["c"]);  // custom hook
  const isCopyMode = keyStates["c"];

the use isCopyMode in your drag and drop monitor function and make sure to add isCopyMode to the dependency array of the useEffect.

[evanheckert]

I appreciate the reply, especially with an example! I implemented a similar workaround - it seems something about the native behavior of shift in the browser just can't be prevented, so I went with another key as well.