ComfyUI Drag-and-drop from the Assets panel broken / FULL FIX JUNE 2026

## Title
**Drag-and-drop from the Assets panel BROKEN FULL FIX** / This new fix restores the wrong (lossy) image instead of the original and reintroduces the image embedded full workflow — `extractFilesFromDragEvent` trusts a browser-synthesized re-encode over the available source URL

## Affected versions
- `comfyui-frontend-package` 1.42.15 (bundled as `dialogService-*.js`)
- Likely all versions containing the current `extractFilesFromDragEvent` implementation — the bug predates 1.42.15 and is not new to this release.

## Summary
_**Dragging an image directly from the Assets panel (or any other in-app gallery rendering a `` of an asset) onto the graph does **not** reliably restore the embedded workflow/prompt metadata, even when the underlying asset file genuinely contains it. Instead, ComfyUI falls back to creating a plain `LoadImage` node, as if the dropped file had no metadata at all.**_

This does **not** happen when dragging the same file from the OS file manager — only when the drag source is an `` already rendered inside the ComfyUI page itself (e.g. the Assets panel grid).

## Root cause
`extractFilesFromDragEvent(e)` (in the bundled `dialogService-*.js`, also present in the frontend source under the file that defines drag/drop file extraction) is implemented as:

```js
async function extractFilesFromDragEvent(e) {
if (!e.dataTransfer) return [];
let t = Array.from(e.dataTransfer.files).filter(e => e.type !== `image/bmp`);
if (t.length > 0) return t;
let n = [`text/uri-list`, `text/x-moz-url`],
r = [...e.dataTransfer.types].find(e => n.includes(e));
if (!r) return [];
let i = e.dataTransfer.getData(r)?.split(`\n`)?.[0];
if (!i) return [];
let a = await (await fetch(i)).blob();
return [new File([a], i, { type: a.type })];
}
```

It prefers `dataTransfer.files`, and only falls back to fetching the genuine resource via `text/uri-list` if `dataTransfer.files` is empty. The `image/bmp` filter shows the author was already aware that browsers synthesize a throwaway re-encoded image file when you drag an in-page `` element (rather than handing over the original bytes) — but the filter only excludes the BMP encoding.

In practice (confirmed on Chromium/Chrome), dragging an `` whose `src` is a same-origin `/api/view?...` URL can populate `dataTransfer.files` with a synthesized file that is **not** BMP (observed: a small re-encoded JPEG, far smaller than the original and stripped of all metadata) while `dataTransfer.types` simultaneously contains a correct `text/uri-list` pointing at the real resource. Because the filter only excludes `image/bmp`, this synthesized non-BMP file passes through, `extractFilesFromDragEvent` returns it instead of the real file, and `handleFile()` correctly determines (correctly, given what it was handed) that there's no embedded workflow — so it falls back to creating a `LoadImage` node.

The exact synthesized format/size is a browser/version implementation detail and isn't a stable signal to filter on. The `text/uri-list` (when present and same-origin) is a much more reliable signal that the drag originated from an in-page image element backed by a real, fetchable resource, and should be preferred over whatever the browser happened to synthesize into `Files`.

## Steps to reproduce
1. Generate or have an existing output PNG with embedded `prompt`/`workflow` metadata.
2. Open it in the Assets panel (`--enable-assets` or default in newer builds where the panel ships).
3. Drag the thumbnail directly from the Assets panel onto the graph canvas (not via the "•••" → "Open as workflow in new tab" action, which works correctly).
4. Observe: a `LoadImage` node is created with no workflow restored, instead of the full graph loading.
5. Compare with: dragging the exact same file from the OS file manager onto the canvas — this works correctly and restores the workflow.

## Expected behavior
Dragging an asset's thumbnail from inside the app should restore its embedded workflow exactly as well as dragging the same file from the OS would — since the panel already has byte-for-byte access to the original resource at the URL the `` is loaded from.

## Suggested fix
Reverse the priority: try the `text/uri-list`/`text/x-moz-url` resource first (when present), and only fall back to `dataTransfer.files` if there is no URL to fetch (i.e. a genuine OS-level file drag, which doesn't populate a URL type at all):

```js
async function extractFilesFromDragEvent(e) {
if (!e.dataTransfer) return [];
let n = [`text/uri-list`, `text/x-moz-url`],
r = [...e.dataTransfer.types].find(t => n.includes(t));
if (r) {
let i = e.dataTransfer.getData(r)?.split(`\n`)?.[0];
if (i) {
try {
let resp = await fetch(i);
if (resp.ok) {
let blob = await resp.blob();
return [new File([blob], i, { type: blob.type })];
}
} catch (_) {
// fall through to dataTransfer.files below
}
}
}
return Array.from(e.dataTransfer.files).filter(f => f.type !== `image/bmp`);
}
```

This preserves existing behavior for real OS file drags (no `text/uri-list` present → unchanged code path) and fixes in-app `` drags by preferring the authoritative same-origin resource over whatever the browser happened to synthesize into `Files`.

I patched and verified this fix locally against a running instance (both the regression case — genuine OS file drag — and the bug case — in-app drag with a synthesized non-BMP file alongside a valid `text/uri-list` — were tested before/after) and can confirm it resolves the issue without affecting normal drag-and-drop.

## Workaround until fixed
Use the asset card's "•••" (More options) → **"Open as workflow in new tab"** action instead of dragging — it already fetches the asset server-side and doesn't hit this code path.

---
Credit: Alex DOYLE FULL Broken Drag&Drop FIX 2026

Search the frontend source for the extractFilesFromDragEvent entry point and compare it with the bundled dialogService implementation. Reproduce a drag from the Assets panel and an OS file drag, then verify that the in-app drag restores the embedded workflow while normal file dragging continues to work.

Written by the indexing model from the issue text.