Able to reproduce the issue with SiteIsolation enabled, Unable to reproduce when SiteIsoaltion is disabled.

Able to reproduce the issue on Chrome Canary(69.0.3465.0), Dev(69.0.3452.0) and Beta(68.0.3440.25) as well.

Thanks for the report!  Confirmed that dragging the grey <div> doesn't show the iframe content in the dragged image when site isolation is enabled.  +paulmeyer, who worked on drag-and-drop OOPIF support in  issue 647249  - any ideas?  Did this never work for OOPIFs, or is it a regression?

We'll need to update DraggedNodeImageBuilder to make this work =(

As far as changes go, this one seems is quite complex. Making it work like the printing path (http://goo.gl/CF1RUy) seems like it'd make sense, but:

1) It's quite complicated. The printing plumbing itself is non-trivial and not easy to re-use for non-printing paths. In addition, drag and drop has its own special behaviors, and it's not clear how well that would fit into the existing models.
2) It's unclear how much delay we can tolerate before beginning the drag operation.

(2) is a pretty big problem; at least on Mac, there doesn't seem to be a public API for changing the drag image dynamically: https://cs.chromium.org/chromium/src/content/browser/web_contents/web_drag_source_mac.mm?rcl=d800ce8818f2a9dcd873c92ca30809e4f1c1132f&l=227

Which means if we want a correct drag image, we'd need to wait for all renderers to provide the content.

Alternatively, we could try to provide snapshots so we don't need to go renderer -> browser -> utility (to render the resulting drag image) -> browser (to begin the actual drag and drop), but that doesn't seem particularly viable either...

#2: it's never worked, we just missed it

jcrys...@: Thanks again for the report!  For context, is there a site this is affecting in the wild that you could share?

dcheng@: I'm not sure I understand the comparison to the printing utility process.  The surfaces we need are in the browser process already for compositing, right?  Could it mainly be a matter of picking out which part of the surface to use for the drag image?  (I'm sure there's more problems that I'm not aware of.)

We can take a snapshot of the iframe and it’s children in the compositor. 

I'm not sure if we need to go to the utility process. I was thinking it might be nice to be able to use the layout paths that we already need for printing (to capture the locations of cross-process surfaces so they can be composited together); however, we can't play back that back in the browser process. If there's something simpler we can use, that would be fine with me too.

(I'm not quite sure how the layout test helpers for dumping the image works, but probably that would be another option as well)

+creis - I don't have a site to share which exhibits this problem, since you would need credentials to log into our application. For context, we're using this react drag-n-drop library https://github.com/react-dnd/react-dnd. We have a sortable list such as this http://react-dnd.github.io/react-dnd/examples-sortable-simple.html where each item in the list has iframe embedded content in it. More specifically, each item in the list includes a Rich Content Editor via Tinymce (see https://www.tinymce.com/). When the user attempts to re-order the list, there is no "ghost" preview of what they are dragging, since the content is rendered in the tinymce iframe. They can still re-order items, but the user experience is unexpected and confusing.

Comment 7: Thanks for the context.  I agree it's unexpected for that content to not be displayed during the drag, and I can confirm it by putting a cross-site iframe into one of the list elements of http://react-dnd.github.io/react-dnd/examples-sortable-simple.html using Chrome's DevTools.

(Interestingly, the dragged element on that page doesn't show up if you drag it lower in the list, if it has an iframe in it. That's true with or without Site Isolation.  Also, you can't drag it at all in Firefox when you put an iframe in it.)

We're looking into options for how to address this on the Chrome side, but it does sound like it might involve a large change.

I'm curious if we can help find a workaround in the meantime, to make it slightly less confusing. 
 For example, maybe it's possible to put a placeholder image at a z-index behind the iframe such that it's visible during the drag?  (That might require making the iframe itself opaque, since they're transparent by default.)