Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.2 using chrome latest stable M55-55.0.2883.87 by following steps mentioned below.

1. Navigated to link https://plnkr.co/edit/MBw2QdfqCKiZSyRUJKAu?p=preview
2. Dragged using mouse from blue area observed the content is draggable
3. Placed the cursor on the small red area and tried to drag, observed the content is not draggable

Note: This issue works fine on firefox and IE browsers.

This is a non-regression issue seen on earlier version of chrome M35-35.0.1849.0 as well, Hence marking it as untriaged.

Thanks!

Thank you for the quick response. 

The plunker is basic but I can extend it, if that helps.

Thank you very much for reporting the issue!

Our behavior is definitely unintuitive and should be fixed. That being said, Safari (WebKit) has the same behavior, so you shouldn't rely on this working correctly in your application.

I suggest doing the DOM change in a separate microtask, for example
Promise.resolve().then(() => overlay.style.display = 'block');

CL with failing test: https://codereview.chromium.org/2606333003/

Initial findings (mostly notes for myself) -- this is happening because MouseEventManager::tryStartDrag first dispatches dragstart, and then calls DragController::startDrag, which performs a hit test and decides to abort the drag. The "original node being dragged isn't under the drag origin anymore..." comment in DragController::startDrag implies that our behavior is intentional.

Thank you for the quick response on this bug. 

Our application is intentionally limited to run in a very limited set of browsers and versions. Edge and Firefox do not have this issue, but they have another ones :) (I'm sure you know about all of them).

That said, I felt like reporting this issue since, in my opinion, it is a very basic and core feature of the D&D manager it should be supported and fixed in Chrome.

#7: I agree that our behavior should be fixed, although I don't think it's a "basic" feature -- you're mutating the DOM around the dragged element in a rather peculiar way. I tried to give you a solution until we get around to fixing this issue.

Based on the code, our behavior is intentional, so it'll take a while to understand the implications of changing it, and whether it's feasible to do so. Also, this isn't a critical bug, so a fix would go through dev and beta before it reaches stable. So, you're looking at months before you could use a fix.

Assuming you bumped into this problem while building an application for your users, I imagine that you're not able to wait for a few months to get the issue fixed. My suggestion above was meant to get you unblocked, so you can ship what you're trying to build.

Hello, 

Knowing that this issue is going to be fixed is enough at this moment. It's okay if it gets fixed in 57, some next canary or so.

The plunker attached to this issue is intentionally simple and tries to hit this bug directly: the drag operation gets cancelled without further explanation. I can tell you our app uses drag and drop in a far more sophisticated and complex way but I tried to simplify the scenario to a minimum, just for the purpose of this thread. 

Anyway, I will try to adapt your workaround to our scenario to see if that helps while you work on the final fix.

Thank you very much.

Hello, 

Any news on this? It's been almost 2 months without any update :(

Thanks in advance

It's not a regression and not high priority. I would not expect any update until an actual fix is pending.

This bug was reported like 3 months ago and hits a basic but core drag and drop scenario.

Please, consider working on this issue as soon as possible. 

Thank you very much from our whole team at Kapsch.

#12: I understand your frustration but, as was stated above, this bug has a low priority for us. It's not a regression and it has an easy workaround. We'd appreciate it if you used stars to express your support for the bug, and only comment if you have information that can help fix the bug.

If you have spare engineering time, it'd help if you'd dig into the revision history for Chrome and WebKit and found out why we're intentionally doing things the way we're doing them (see my comment #6). The fix seems pretty straightforward (remove the special case), and I have put together a test for it, but I'm currently wary of making a change because I don't currently understand why we have that special case to begin with.

I hope this helps!

 Issue 774422  has been merged into this issue.

I was able to reproduce on Chrome Canary 70.0.3530.0 on MacOS.