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

[AlexandreDoyle]

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 <img> 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 <img> 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:

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 <img> element (rather than handing over the original bytes) — but the filter only excludes the BMP encoding.

In practice (confirmed on Chromium/Chrome), dragging an <img> 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 <img> 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):

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 <img> 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

[coderabbitai]

🔗 Related PRs

#11716 - fix(assets): dedupe outputs by composite key to prevent media asset panel scroll-duplication [merged]
#12328 - fix(asset-card): read image dimensions from typed metadata field [merged]
#12654 - fix: defer node auto-pan until drag starts [merged]
#12900 - Fix 'insert as node' in sidebar tab [merged]
#13024 - fix(test): de-flake Canvas ctrl+shift+vertical-drag zoom e2e [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dante01yoon]

Thanks for the report and PR . Can you also give showcase examples when/which scenario did you meet issues in realworld - could you post screenshot or video

[AlexandreDoyle]

Sure — here's the real-world scenario, fully deterministic, no contrived setup:

Setup: comfyui-frontend-package 1.42.15, ComfyUI launched with --enable-assets.

1. Run any normal sampler → SaveImage workflow. The output PNG has prompt/workflow embedded — verifiable independently with Image.open(path).info["workflow"].
2. Open the Assets panel, find that output.
3. Drag the thumbnail (the in-panel ) directly onto the canvas.
4. Result: a bare LoadImage node is created — the embedded workflow is dropped, despite the file genuinely containing it.
5. Control: drag that exact same file from the OS file manager instead. The full workflow restores correctly, every time.

Steps 3 vs 5 are the isolating signal — identical bytes, identical browser tab, the only variable is the drag source. That's consistent with extractFilesFromDragEvent picking up whatever the browser synthesizes into dataTransfer.files for an in-page drag (a re-encoded, metadata-stripped copy) instead of the text/uri-list entry that's also present and points at the real resource — which is exactly what the patch in the issue reprioritizes.

For the video... Would be hard to reproduce... Explanation.

This issue happened to me as I was refounding the back-end of my live webUI gallery app that I'm working on binding directly to ComfyUI. Something had broken in comfyUI with the assets images not restoring the embedded workflow associated with the selected image. After a quick search online, I realized I wasn't the only one running into this issue, something had broken or regressed in the code, so I decided to look into it more thoroughly with a little help from Claude Opus 4.8 -

After studying a few modifications I had made and some tampering with the rollbacks, from different snapshots with my original gallery code that I had decided to run a comparison script on, I finally came to zero-in on the problem. It had nothing to do with comfyUI's back-end , but more with how the assets panel front-end was writing to the gallery images, and in the process, I enriched the metadata encoding (mistakingly thinking it could be a good promotion, but broke the way the interpreter from comfyUI was parsing the info, resulting in a small mess in the SQL registry also. So I reconfigured the original code to the way it interprets the drag-drop functions of the images and the way the loader interpreter parses the info. Then back-engineered from there and cross referrenced the results in Claude to find a solution. To which it did - and it works - Fully tested. No more size restrictions, or blank workflows or simple image loader node imports.

Also, in doing that, I then realized that I also had an origin point to this problem. I mistakingly misconfigured some code in my gallery backend and that's where the problem started originally. It was my own gallery itself that was not correctly registering / parsing the images info after I decided to change the way the gallery would reload in relatime, injecting some lazy load instructions (amongst optimizations). SO - in the end, what really happened, is that it wasn't ComfyUI that originally was not reading/ retaining the workflow metatags from the images - It was my own gallery that was corrupting them on the fly - hence drag&drop back into the comfyUI not working anymore, but I think it broke something right there and assets panel functions regressed.
Combined with the earlier finding that the gallery's metadata-serving and /images/ file-serving were both untouched and provably correct, this is the most consistent explanation: it's not gallery content that was broken, it's that the gallery never sent CORS headers, and something in ComfyUI's drag handling now requires that fetch to succeed.

In other words, I accidentally created this issue myself by accident, but when looking into it to resolve it , (thinking it was on comfyUI's side) I eventually resolved an exact similar issue that other users online were having, (maybe not originating from the same cause). Although this gives a clearer idea of what's going on in relation the the way the embedded metadata is encoded / parsed and ComfyUI's JS from reading the response body of cross-origin fetch, the info can get corrupted by other image related programs or SQL DB confiugurations. //AD.