UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
1. Open at least two tabs.
2. Start dragging one of them.
3. While your pointer is held down (so you are still dragging a tab), press the keyboard shortcut to open a new tab. (⌘T by default on macOS)
4. Observe that as you continue to drag the originally dragged tab around, the newly opened tab follows you around almost as if it were being dragged as well. It hops from slot to slot.
5. Release your held pointer and observe that the newly added and originally dragged tabs separate (and return to their ordered tab positions).

What is the expected behavior?
It isn’t 100% clear what the correct behavior should be.

I would put forward that a reasonable solution would be to force the dragging to end as if the user had mouseup’d, put it into the nearest open slot, and then in the next frame start the opening of the new tab (which can still be animated).

What went wrong?
It shouldn’t ever be the case that the user can move around the newly opened tab even though they never initiated a "dragStart" on it.

Did this work before? N/A 

Chrome version: 71.0.3578.98  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

I recently had to solve this issue for my DOM-based implementation of Chrome Tabs.

You can see how I solved it by following the repro steps here:
https://adamschwartz.co/chrome-tabs/

(Note: it uses ⌃T instead of ⌘T since AFAIA ⌘T cannot be event.preventDefault()ed.)
 

Deleted: google-chrome-tabs-issue-when-opening-a-new-tab-while-dragging-another-tab.mov 707 KB

	google-chrome-tabs-issue-when-opening-a-new-tab-while-dragging-another-tab.mov 707 KB View Download