More complex promoted widgets in subgraphs are no longer correctly displayed in latest version

[Stibo]

Custom Node Testing

• I have tried disabling custom nodes and the issue persists (see how to disable custom nodes if you need help)

Expected Behavior

Promoted subgraph widgets like "lora_1" etc. from "Power Lora Loader" by rgthree are normally displayed on the subgraph.

Actual Behavior

Promoted subgraph widgets like "lora_1" etc. from "Power Lora Loader" by rgthree take up space but are "invisible".

Steps to Reproduce

There are other widgets affected, but I use Power Lora Loader by rgthree as a sample here:

1. Be sure you have at least ComfyUI 0.18.1 with frontend version 1.42.8
2. Add a Power Lora Loader node
3. Convert the node to a subgraph
4. Edit promoted subgraph widgets
5. Promote "lora_1", "lora_2", "lora_3" widgets to the subgraph (how many is not important)
6. Look at the subgraph and see that there is something invisible taking space

Debug Logs

No error occures, just a visual rendering issue.

Other

I don't know since when this issue persist, I skipped a few versions and firstly saw the issue with ComfyUI 0.18.1 with frontend version 1.42.8:

Most of the "normal" widgets work as expected. More complex nodes like Power Lora Loader are a problem. In my extension (https://github.com/Stibo/comfyui-nifty-nodes) I had the same issue with a special node, but I was able to fix it more or less hacky.

Multiling String nodes have some issues too, if they are promoted and then collapsed, the multiline string widget disappears from the subgraph (maybe just invisible too).

I think there is a general issue with the widget rendering in the above mentioned versions.

[byteconcepts]

Here, too. Nodes < 2.0

They are invisible, but are there and even fully functional if you can guess where the interactive GUI Elements are.

But the subgraph does not adjust it's size to the embedded invisible GUI elements, so overflow=hidden.

[zqwdzh]

自定义节点测试

• 我已尝试禁用自定义节点，但问题仍然存在（如果需要帮助，请参阅如何禁用自定义节点）。

预期行为

来自 rgthree 的“Power Lora Loader”的“lora_1”等推广子图小部件通常会显示在子图上。

实际行为

来自 rgthree 的“Power Lora Loader”的“lora_1”等推广子图小部件会占用空间，但却是“不可见的”。

重现步骤

还有其他组件也会受到影响，但这里我以 rgthree 的 Power Lora Loader 为例：

1. 请确保您已安装 ComfyUI 0.18.1 或更高版本，前端版本为 1.42.8。
2. 添加一个 Power Lora Loader 节点
3. 将节点转换为子图
4. 编辑推广的子图组件
5. 将“lora_1”、“lora_2”、“lora_3”组件提升到子图（数量多少并不重要）
6. 观察子图，你会发现有看不见的东西占据了空间。

调试日志

No error occures, just a visual rendering issue.

其他

我不知道这个问题是从什么时候开始出现的，我跳过了几个版本，第一次遇到这个问题是在 ComfyUI 0.18.1 和前端版本 1.42.8 之间：

大多数“普通”组件都能正常工作。但像 Power Lora Loader 这样更复杂的节点却会出现问题。在我的扩展程序（https://github.com/Stibo/comfyui-nifty-nodes）中，我也遇到过类似的问题，不过我最终用一种比较取巧的方法解决了这个问题。

多行字符串节点也存在一些问题，如果它们被提升然后折叠，多行字符串小部件就会从子图中消失（也可能只是不可见）。

我认为上述版本中的控件渲染存在普遍问题。

I've encountered the same issue. Based on my testing, it appears to be a problem in versions 0.15.0 and later.

[rafstahelin]

Confirming this with a minimal repro on a clean workflow. The core observation that may be useful: the
value DOES propagate to the inner node — only the surface display is desynced. Workflows still execute
with the new value; the bug is purely visual, but it makes promoted widgets unusable as a control surface.

Repro

1. Drop a fresh KSampler into an empty workflow
2. Select all its widgets, "Convert Selection to Subgraph"
3. On the subgraph node, change cfg from 8.0 to 1.0
4. Surface still displays 8.0
5. Double-click into the subgraph → inner KSampler shows 1.0 ✓

Affects every promoted widget type tested (cfg, seed, steps, denoise, sampler_name, scheduler). Not
workflow-state-specific — reproduces in fresh Load Default workflows.

Versions tested

┌──────────┬───────────────────┬──────────────────────────────────┬─────────────┐
│ Frontend │ Backend │ NIGHTLY badge │ Bug present │
├──────────┼───────────────────┼──────────────────────────────────┼─────────────┤
│ 1.43.1 │ v0.20.1 (cf9cbec) │ yes │ yes │
├──────────┼───────────────────┼──────────────────────────────────┼─────────────┤
│ 1.43.0 │ v0.20.1 │ yes │ yes │
├──────────┼───────────────────┼──────────────────────────────────┼─────────────┤
│ 1.42.15 │ v0.20.1 │ no │ yes │
├──────────┼───────────────────┼──────────────────────────────────┼─────────────┤
│ 1.42.14 │ v0.20.1 │ n/a — compatibility floor blocks │ │
└──────────┴───────────────────┴──────────────────────────────────┴─────────────┘

The supported stable window for backend v0.20.1 is exactly 1.42.15, and that version reproduces. There's
no stable frontend that satisfies the backend floor and avoids this bug.

Environment

• ComfyUI v0.20.1-23-gcf9cbec (master, 2026-05-01)
• comfyui-frontend-package per table above
• Windows 11, Chrome (hard-reload, single user, no PWA cache)
• RTX 4090, 24GB VRAM
• Reproduces with all custom nodes disabled

Note for triage

If a fix exists on a 1.43.x nightly that isn't backported to 1.42.x stable, a stable patch release would
unblock anyone on backend v0.20.1. Currently the only escape is to roll back the backend itself.