I think I'm wrong about the flag having to be set to enabled.

It only happens when this new context menu is on. It's very inconsistent, sometimes I see the new MD context menu and sometimes I see the older version. I assume the MD context menu and the MD download shelf are related...

Deleted: Screen Shot 2018-06-30 at 5.09.31 PM.png 60.1 KB

	Screen Shot 2018-06-30 at 5.09.31 PM.png 60.1 KB View Download

Can you please record a screencast and attach it here to the bugreport? Thanks.

What's also weird is that after dragging the file from the download shelf it automatically opens the file. You can see this happening when it tries to open the .zip file.

Deleted: Untitled.mov 6.2 MB

	Untitled.mov 6.2 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is how it is supposed to work. There are also hover animations missing in the MacViews version.

Deleted: Untitled.mov 2.4 MB

	Untitled.mov 2.4 MB View Download

Thanks for the screencasts. Confirmed in latest Canary under MacViews.

Able to reproduce the issue on reported chrome version 68.0.3440.42 and on the latest canary 69.0.3478.0 using Mac 10.13.1. Hence providing the bisect info.

Bisect Information:
===================
Good Build: 67.0.3379.0
Bad Build:  67.0.3381.0

Providing the Change log from https://omahaproxy.appspot.com/ as we are unable to do per-revision bisect due to perf errors and in chromium bisect, the invoked version doesn't have the flag #enable-google-branded-context-menu to check and confirm.

Change log:
https://chromium.googlesource.com/chromium/src/+log/67.0.3379.0..67.0.3381.0?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/20551064d1dd275d1264d4b2543e8b9fb1f934f8
Review URL: https://chromium-review.googlesource.com/979195

@Sidney San Martín: Please help in assigning it to the right owner if this is not related to your change.
Note: Tagging with M-67 milestone, as the issue is seen in latest stable 67.0.3396.99

Thanks!

This still occurs and is a regression. Was fixed in https://bugs.chromium.org/p/chromium/issues/detail?id=822416 but is broken again.

This works for me in 70.0.3513.0 and 69.0.3497.23 - what version are you using? Can you provide exact repro steps?

69.0.3497.23.

Make sure #views-browser-windows is enabled

1. Download a file. I used one from https://www.thinkbroadband.com/download

2. Wait until completion. You should see the downloaded file in the download shelf

3. Open Finder window. Make sure the window is focused, but the download shelf is visible.

4. Hover over file in download shelf. The colour of the downloaded item should become darker but it does not. With MacViews off (#views-browser-windows

 is disabled) if you hover over it while Finder is focused it still changes colour.

5. Try to click and drag downloaded file into Finder window. It doesn't work. The finder window hides.

Another thing, if you try to cancel the drag by pressing Escape key, it tries to OPEN the downloaded file instead. I.e. if you downloaded a .zip file, and try to drag and press Esc, it extracts the .zip instead. This did not happen with MacViews off.

Try the above with #views-browser-windows enabled and disabled and you can see a lot of differences in the behaviour.

In this video I try to drag a file from download shelf and try to cancel it by pressing Esc key. With MacViews off it cancels the action. With MacViews on it opens the file instead.

Deleted: macviews off.mov 1.7 MB

	macviews off.mov 1.7 MB View Download

Deleted: macviews on.mov 895 KB

	macviews on.mov 895 KB View Download

OK - retitling to reflect what I think is going on (sdy - can you take a look?)

The drag works so long as the windows do not completely overlap, but currently Chrome always activates its window on mousedown, which may hide Finder. You can reactivate Finder by hovering over its Dock icon, but that's annoying.

+elly in case this needs reprioritization, but this might be OK to live with for a milestone.

We're going to have to live with this until M70 - the M69 merge window is closing and I don't think a fix to this will end up low-risk based on past experiences with the drag code.

+cc avi@ who is looking at a drag rework

Hi, this is a pretty annoying issue that still exists. Any updates?

I found a temporary workaround: Hold Cmd key while dragging.