The supplied repro URL does not appear to have any demonstration of the described behavior. Is that the right URL?

https://jsfiddle.net/pranjaljaju/9x0mmsey/

Look at this fiddle

Confirmed repro in M54 and M55.

Perhaps this operation is now getting classified as an attempted "selection" as only SHIFT has this problem, not ALT or CTRL.

Not repro in 53.0.2769.0 (Developer Build) (32-bit) e6fb262ca88b0a3bc10ba7deb8a03e1d3acbf355-refs/heads/master@{#399957}

This appears to be an intentional change, likely regressor: https://chromium.googlesource.com/chromium/src/+/40285d7edd6ab066b3a9c8756416ea7395b2eb55

By when this can be fixed

This appears to be an intentional change and old behavior likely will not be restored. Star this issue for updates. 

I understand the rationale behind this change (https://chromium.googlesource.com/chromium/src/+/40285d7edd6ab066b3a9c8756416ea7395b2eb55), but shift+drag is a common UI pattern that is no longer possible because of this (on elements other thank links/images). I wonder if it's possible to detect if there is currently text under the cursor on click?

tonikitoo@ Would you mind triaging this?

Chrome55 now behaves differently than Firefox52a1 when shift+dragging in the repro in #3

elawrence@ yes, I will have a look.

 Issue 650244  has been merged into this issue.

@tonikitoo: Are you still working on this issue? Feel free to assign me if you're not.

Reproduced on Mac with Chrome stable (53.0.2785.143).

Safari 10.0 (11602.1.50.0.10) currently behaves the like Chrome. Firefox stable (49) and nightly (52) fire the dragstart event. So, at this point, we're not the odd one out anymore.

I noticed that we don't do text selection on draggable elements. I could look into not blocking Shift-dragging when the cursor is above an element with draggable="true"

@pwnall: Hi. Sorry, I should have a patch for it today.

@tonikitoo: Thank you for responding so quickly!

Also, no rush -- I just needed to know if this is still on your plate.

I could finally get a slot of time to fix this regression. I have uploaded a trial patch to https://codereview.chromium.org/2407193003 . Will get bots running on it, and will work on a layout test in the meanwhile.

I am also having this issue and rely on SHIFT for various operations while dragging.

Simple example:
https://jsfiddle.net/sqrbnaqw/

This has been plaguing us in our app for months. We thought it was do to a refactor that broke shift drag-and-drop, but have since realized it is a result of this bug. I’m happy to see that @tonikitoo made a patch for the bug. Is there anything I, or anyone else in the community who is effected by this bug, can do to help test the patch or in any way help this move towards resolution?

Thanks for all of your efforts!

Is there an update on this yet?

Hi, there seems to be a patch by @tonikitoo that would fix the issue, would you mind testing it / shipping it ?

This is still a very irritating issue, two years later. Is there any reason that @tonikitoo's patch hasn't been tested or released yet?

 Issue 729445  has been merged into this issue.

I was able to reproduce this issue on Chrome Canary 70.0.3528.0 on MacOS.

The missing piece here is a test. Sorry, I haven't had time to get to it.

huangdarwin@ might be able to look into this.

huangdarwin@ is looking into getting test coverage for this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3f5912ba03f3362f32d3cb3e0f382a41555495a6

commit 3f5912ba03f3362f32d3cb3e0f382a41555495a6
Author: Darwin Huang <huangdarwin@chromium.org>
Date: Tue Sep 18 23:33:20 2018

DataTransfer: Fix drag-and-drop while Shift is held down.

drag-and-drop wouldn't initiate when shift was held down
- Reproduced bug by adding layout tests in third_party/WebKit/LayoutTests/fast/dnd/dropEffect-for-modifier-*.html
- Fixed bug in selection_controller.cc

R=pwnall@chromium.org

Bug:  646339 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I57bb7071d0db81364aa5d2113c93a4cbf9fc09f2
Reviewed-on: https://chromium-review.googlesource.com/1223032
Commit-Queue: Darwin Huang <huangdarwin@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592257}
[add] https://crrev.com/3f5912ba03f3362f32d3cb3e0f382a41555495a6/third_party/WebKit/LayoutTests/fast/dnd/dropEffect-for-modifier-leftControl.html
[add] https://crrev.com/3f5912ba03f3362f32d3cb3e0f382a41555495a6/third_party/WebKit/LayoutTests/fast/dnd/dropEffect-for-modifier-leftShift.html
[add] https://crrev.com/3f5912ba03f3362f32d3cb3e0f382a41555495a6/third_party/WebKit/LayoutTests/fast/dnd/dropEffect-for-modifier-nokey.html
[modify] https://crrev.com/3f5912ba03f3362f32d3cb3e0f382a41555495a6/third_party/WebKit/LayoutTests/fast/dnd/resources/dropEffect-common.js
[modify] https://crrev.com/3f5912ba03f3362f32d3cb3e0f382a41555495a6/third_party/blink/renderer/core/editing/selection_controller.cc

As noted by bugdroid, this issue should now be fixed via https://crrev.com/c/1223032. Please let me know if that CL isn't sufficient or if the bug persists.

Hello,
I have checked original fiddle on fresh Chromium build and confirm this case has been fixed. 

But, I came here from https://github.com/react-dnd/react-dnd/issues/683 and on react-dnd scenarios the issue still reproducible. Though I don't know how it works internally.

I've checked react-dnd example and can confirm all examples work except Native Drag Layer (https://react-dnd.github.io/react-dnd/examples-drag-around-custom-drag-layer.html) which I believe must be the library issue.
Thank you for the fix.

Thank you for confirming the fix :)

I'm not sure why it doesn't work with react dnd, but I'll assume it's a library issue as other examples work.