Thanks for the report. Can you reproduce this issue also with latest Chrome Canary?

Thanks in advance.

Just to clarify: 

When I try to repro this, I get a toast from Photos saying that the upload failed. Is that what you're seeing or just no reaction at all?

Yes I can repro on Chrome Canary, I see no reaction at all, see: https://photos.app.goo.gl/ttkoixvkUtxKSNbQ6

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

Based on the video, I think this might be on the Google Photos side. In the video, I see a toast pop up with a preview thumbnail (in the bottom left), which tells me Photos got *something* in the drop event that it could read. Have you run into this with anything besides Photos?

Same happened in Drive. Sadly, I just updated to Mojave (10_14_2) and can no longer repro myself, dropping from Apple Photos to Chrome work fine in Mojave.

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

Someone else on my team is still on High Sierra and can repro with this fiddle: https://jsfiddle.net/pr1qnz4t/11/

As per comment #0 and comment #10, able to reproduce the issue on reported chrome version 71.0.3578.98 also on latest chrome 73.0.3643.0 using Mac 10.13.6.  
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Note: Issue not seen on Mac 10.14.0. 

Thanks..! 

+avi@ who has some context on this (but note that per c#11 it's non-regression)

This is entirely an issue with Photos.

Chrome wants a drag of a file on disk; Photos is not providing that even though the photos are backed by files on disk. Alternatively, if Photos were providing a drag with image data, at least we could work with that, but it doesn't do that either.

Photos (1.5 (370.42.0)) on my Mac (10.11.6 (15G22010)) provides the flavors:

item 0
- PboardType "Apple files promise pasteboard type"
- UTType "com.apple.pasteboard.promised-file-content-type"
- UTType "com.apple.pasteboard.promised-file-url"
- PboardType "NSPromiseContentsPboardType"
- UTType "com.apple.UXCollectionView.sourcepointer"
- PboardType "IPXPasteboardController"
- UTType "com.apple.PhotoPrintProduct.photoUUID"
- Flavor 'phfs'

item 1
- UTType "com.apple.UXCollectionView.draggingitem"

These flavors are either
1) useful only to Photos itself
2) useful only to the Finder to materialize a file drag

Nothing useful is provided to a non-Apple app to do something with the drag. This requires a change from Apple.

I'm kinda curious what Safari is doing. Is it materializing files just to send them to the web?

Repro'ed on OSX 10.12 Chrome 71.0.3578.98 vs Safari 12.0.2. 

I tried dragging 2 images (one as .jpg, one as .png) from Apple Photos to Chrome and Safari, with website http://madebyevan.com/clipboard-test/ as the drop target. Safari sees a drop target with type image/jpeg or image/png, respectively. Meanwhile, Chrome doesn't seem to see any drop event at all, so no reaction at all for me.

This one bug has people both reporting no reaction, which I'm also experiencing, as well as an error.

Without much context here... "Apple files promise pasteboard type" seems to map to NSFilesPromisePboardType which Safari does handle, but Chrome seemingly does not (well, Chrome populates in content/browser/web_contents/web_drag_source_mac.mm but doesn't accept?)

Per https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DragandDrop/Tasks/DraggingFiles.html - "in essence, the drag operation contains a promise from the source to the destination that the source will create the specified files if the drag operation is accepted"

As per #13 and #16, Apple seems to be using a special Promise-based pasteboard type, which is useful/used-in only to Apple products at this time. Either Apple should provide more types in the drag and drop event, or Chrome should make this a feature request to support this type.

https://lists.apple.com/archives/cocoa-dev/2015/Apr/msg00448.html is interesting.

The documentation for namesOfPromisedFilesDroppedAtDestination says:
"The source may or may not have created the files by the time this method returns."

so I wonder if Safari checks there and processes into a more digestible drag type if the file is available.

If the file is available, none of this matters. You'll get an actual file drag type.

Promised files are a disaster. When promising file drags *out* of Chrome we use the 10.2 API because the 10.6 "modern" API is busted, and the replacement file promise API is >= 10.12.

The proposal is that if all we get is a file promise, to materialize the promise and then to provide that to the page. The link that Leonard points to is for the 10.2 API for which you have no idea when the file is actually written. As for the new API...

Read the header file:

"""
The reader block is called on the supplied operationQueue when the promised file is ready to be read. When the source is an NSFilePromiseProvider, the readerBlock call is wrapped in an NSFileCoordination read. Otherwise, a heuristic is used to determine when the promised file is ready to be read.
"""

So if the file source is also using the modern API you get guarantees that the file is completely written. If the file source is using old APIs, the system will guess for you (well, you'd have to guess yourself if it didn't so hey).

I'm curious what Safari does. Is it materializing the dropped files? Does it secretly know about the Photos drop flavors?