Copy+paste doesn't work anymore since 1.30.2

[geroldmeisinger]

Prerequisites

• I am running the latest version of ComfyUI
• I have searched existing issues to make sure this isn't a duplicate
• I have tested with all custom nodes disabled (see how)

What happened?

A simple copy+paste of text doesn't work anymore since 1.30.2

1.32.4 broken
1.32.0 broken
1.31.0 broken
1.30.3 broken
1.30.2 broken
1.30.1 working
1.30.0 working
1.29.3 working
1.29.0 working
1.28.8 working

the changelog mentions:
https://github.com/Comfy-Org/ComfyUI_frontend/releases/tag/v1.30.2
Support cross domain/application copy/paste by @AustinMroz in #6087

Steps to Reproduce

uv pip install comfyui-frontend-package==1.30.1
uv run main.py --front-end-version Comfy-Org/ComfyUI_frontend@1.30.1

uv pip install comfyui-frontend-package==1.30.2
uv run main.py --front-end-version Comfy-Org/ComfyUI_frontend@1.30.2

load something with a missing model and try to copy+paste the text

How is this affecting you?

Feature doesn't work as expected

ComfyUI Frontend Version

1.30.2

Browser

Firefox
Cinnamon Desktop Manager
Debian Linux

Console Errors

Logs

Additional Context

similar issues: #6660 #6993 #5449 #6822 #6485 #5683

┆Issue is synchronized with this Notion page by Unito

[dosubot]

Copy-paste stopped working after 1.30.2 due to changes in clipboard handling introduced for cross-domain/application support (PR #6087). The new logic uses base64 encoding and stricter event target checks, which can break default text copy-paste in some scenarios, especially in Firefox and when focus is lost from the main canvas area.

There are two main root causes:

1. The clipboard logic sometimes fails to recognize the correct UI element as the target, so copy/paste events are ignored if you click outside the canvas or on certain UI controls (example).
2. The use of btoa for encoding node data causes errors if the content includes non-ASCII characters, silently breaking copy (details).

Workarounds:

• Try holding Ctrl+C for a few seconds instead of a quick press—this sometimes refreshes the clipboard cache (source).
• Use Ctrl+Insert instead of Ctrl+C for copying (source).
• Refreshing the browser can temporarily restore copy-paste.
• Avoid copying nodes with non-ASCII/Unicode content if possible.

A permanent fix would require updating the encoding logic to handle UTF-8 (e.g., btoa(unescape(encodeURIComponent(str)))) and expanding the event target detection to reliably include all relevant UI elements. These issues are known and have been discussed in several threads, but as of the latest versions, the regression persists for some users (details, details).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[geroldmeisinger]

@dosu workarounds are not working

[dosubot]

None of the known workarounds reliably resolve the copy-paste issue in recent ComfyUI frontend versions. The bug is a confirmed regression caused by changes to clipboard handling for cross-domain support, specifically the use of btoa for encoding node data, which fails with non-ASCII (Unicode) characters and breaks copy-paste for many users across browsers, including Firefox on Linux. This issue persists even with all custom nodes disabled and in clean installs, and there is currently no permanent fix or new workaround available in the latest releases. A proper solution would require updating the encoding logic to handle UTF-8 safely, but this has not yet been implemented or merged by maintainers. You can track ongoing discussion and technical details in issue #6485 and PR #6087.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[geroldmeisinger]

@dosu the text I copied contained ascii chars only

[dosubot]

Thanks for clarifying. The copy-paste issue in ComfyUI frontend after v1.30.2 is not just about non-ASCII characters—it's also caused by how clipboard events are handled at the document level. The new logic intercepts all copy/paste events unless you're focused on a native input or textarea, and only sets clipboard data for node/canvas operations. This means that copying plain ASCII text from anywhere else in the UI (like dialogs, custom widgets, or error messages) is blocked, regardless of the text content. This is a known regression from the cross-domain clipboard changes and affects basic text copy-paste for all users, not just those with Unicode content. The issue is due to event target/focus handling, not encoding, and there isn't a reliable workaround at the moment—restoring normal text copy-paste will require a code change to the clipboard handler logic.
Reference: PR #6087 clipboard logic

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[jovan2009]

I probably also noticed recently that copying text from frontend error messages doesn't actually put anything in the clipboard. I resorted to copy directly from the server's command line window. I didn't know it used to work before.

Edit: actually I thought at the time I didn't hit properly Ctrl+C, having a wonky wireless keyboard that sometimes doesn't register correctly all the key presses. Seeing this opened issue though, made me recall that moment.

[jovan2009]

I don't know if it's best to write about this in this thread or open a separate feature request ( I probably will do exactly that in the near future).

But here we go for now:

I would like to be able to copy paste the path from one image source node (for example) into another similar image source node. I know I can do that by simply cloning the first image node but I have to remake all the node links again for the new cloned node instead of reusing an already properly linked node.

Edit: even to be able to copy the path from a node would be an improvement when I can't remember from what exact folder I dragged and dropped the image when I did in the first place. Copying at least the name of the file would allow me to easily and quickly use Everything application in Windows (or regular windows file search, which is much slower) to search for it among all my drives and folders. ( Yeah, I'm a little bit disorganized and I have not the best memory. Also I am lazy.)

[geroldmeisinger]

@jovan2009 yes, this should be a feature request, see #6166 and #2892
(what you could do in your case is create a Primitive node and hook it up to all Image Load in which case it becomes a central file selector. you can also get the filename from the url when you click Open Image, but it's clumsy. or use a different custom image loader altogether)

[jovan2009]

Testing for myself in 1.32.5, Windows 11, latest Chrome 142.0.7444.163:

Keyboard Ctrl + C doesn't work.
Right clicking shows some options:

• Copy doesn't work
• Copy link to highlight - I don't know what is that, but puts this in clipboard: http://127.0.0.1:8188/#:~:text=SamplerCustomWithNAG
• Search Google works
• Same behavior if you select the text outside that area, for example the title "Some Nodes Are Missing"