[Bug]: Renamed widgets are not

[chrisgoringe]

Frontend Version

Comfy 0.3.30
Front end 1.17.11

Expected Behavior

If you right click an input you can rename the slot. For non-widget inputs, this change is displayed on the node.

If you right-click a widget (whether or not it is connected) you can rename it. I would expect the new name to be displayed, as it is for an input.

Actual Behavior

A renamed widget does not have the name displayed.

Steps to Reproduce

For any widget:

• right click the input dot
• select Rename Slot
• type a new name
• see that it isn't displayed

Debug Logs

Nothing relevant

Browser Logs

Niothing relevant

Setting JSON

comfy.settings.json

What browsers do you use to access the UI ?

Brave

Other Information

Looking at the javascript console, it appears that editing the name of the slot sets the label attribute of the input (in node.inputs) but doesn't change the label attribute of the widget (in node.widgets). If the label attribute is changed manually in the console, the label displayed updates. The widget label is what gets displayed.

Proposed solution:

When input.label is set, input.widget.label should also be set, if input.widget is defined.

Additional suggestion:

When Rename Slot is selected, if the label is undefined, the dialog box starts empty. It would be more intuitive if it were populated with the value of localised_name, since this is the currently displayed value that is going to be replaced.

┆Issue is synchronized with this Notion page by Unito

[webfiltered]

Rename is simply not implemented for widget input sockets, but they inherited it from regular inputs when they were added.

Rename will be removed until the code is added to even support this.

[chrisgoringe]

Removing it seems the wrong solution… The Use Everywhere nodes make use of names for regex matching - at least now it works, even if not visible!

…

On Mon, 28 Apr 2025 at 1:27 am, filtered ***@***.***> wrote: *webfiltered* left a comment (Comfy-Org/ComfyUI_frontend#3654) <#3654 (comment)> Rename is simply not implemented for widget input sockets, but they inherited it from regular inputs when they were added. Rename will be removed until the code is added to even support this. — Reply to this email directly, view it on GitHub <#3654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBLMA25BUZY2AOMCHWBIEL23TZPLAVCNFSM6AAAAAB36GI3FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZTGUYTEMZZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[webfiltered]

It's not a solution, it's a bug fix - the rename slot option being there was an oversight. For anyone not using your extension, it is a completely broken menu.

Fixing the bug will take <5mins. Adding all the supporting code to implement and test this not-even-started feature, from rendering to serialisation, interop, custom node tests... it's a tiny bit more work.

[webfiltered]

To be clear, I had seen this myself and already planned to remove it when I had a sec.

Knowing that there is demand for this feature is great feedback, though! I'd like to keep this now-feature-request open until it's done.

[diodiogod]

Yes, there is a demand! I also use Everywhere nodes a lot to referenced renamed inputs.

[chrisgoringe]

To be clear, I had seen this myself and already planned to remove it when I had a sec.

Ok - but this is a regression, right? Previously a widget could be renamed (by changing it to an input) and now it can't.

This sort of thing is a problem for third party developers...

[webfiltered]

I mean, sort-of-technically you could call it a regression? Widget conversion was a quick hack needed to be replaced - it has caused many improvements to simply be dropped because it was too time-consuming to work around.

From the code, it seems more like the rename functionality was an unintended side-effect. Otherwise, why didn't the author add anything to do with widget rename?

For your use-case, the following callback could be useful. But... it's kinda garbage because it causes defaults to be discarded (which isn't exactly future-proof or neighbourly). Would you like a new callback - something that sends you the proposed list of context menu options, and allows you to add/modify it?

https://github.com/Comfy-Org/litegraph.js/blob/cfabeb08216114eaeb72a7e73f09d5dee2805380/src/LGraphCanvas.ts#L7165-L7189

[chrisgoringe]

Very glad to see the back of widget conversion! I can live without this at the moment. But if there is going to be a Comfy-specific context menu, I think there ought to be a callback that allows it to be modified - this would be a general rule, IMO. These sorts of callbacks make it much easier to integrate without fragile hacks...

…

On Thu, 1 May 2025 at 19:40, filtered ***@***.***> wrote: *webfiltered* left a comment (Comfy-Org/ComfyUI_frontend#3654) <#3654 (comment)> I mean, sort-of-technically you could call it a regression? Widget conversion was a quick hack needed to be replaced - it has caused many improvements to simply be dropped because it was too time-consuming to work around. From the code, it seems more like the rename functionality was an unintended side-effect. Otherwise, why didn't the author add anything to do with widget rename? For your use-case, the following callback could be useful. But... it's kinda garbage because it causes defaults to be discarded (which isn't exactly future-proof or neighbourly). Would you like a new callback - something that sends you the proposed list of context menu options, and allows you to add/modify it? https://github.com/Comfy-Org/litegraph.js/blob/cfabeb08216114eaeb72a7e73f09d5dee2805380/src/LGraphCanvas.ts#L7165-L7189 — Reply to this email directly, view it on GitHub <#3654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBLMA45MAYA2PJKSARSLOT24HTY7AVCNFSM6AAAAAB36GI3FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUGU2TAMBQGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[webfiltered]

100% - side-stepping around monkey patches is horrific for everyone.

The goal here is to implement this properly using cancellable events; I just need a little bit of time to lock in the design for canvas (it's a bit more complex than what I put in for LinkConnector). So I'll hold off for now, but feel free to ping if a workaround is needed.

[chrisgoringe]

Thx

…

On Thu, 1 May 2025 at 11:26 pm, filtered ***@***.***> wrote: *webfiltered* left a comment (Comfy-Org/ComfyUI_frontend#3654) <#3654 (comment)> 100% - side-stepping around monkey patches is horrific for everyone. The goal here is to implement this properly using cancellable events; I just need a little bit of time to lock in the design for canvas (it's a bit more complex than what I put in for LinkConnector). So I'll hold off for now, but feel free to ping if a workaround is needed. — Reply to this email directly, view it on GitHub <#3654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBLMA4J3RVJLWEHXNFNVY324IOJTAVCNFSM6AAAAAB36GI3FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUHA2DINZWGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>