Open MagicHatJo opened 11 months ago
Can confirm that I have seen this issue. Often happens when attempting to rename a node (node rename box ends up behind the node)
Is there any solution? I believe it only happens on the text widget
Is there any solution? I believe it only happens on the text widget
There is no solution yet. This is a problem that many developers are aware of, already. However, it's an issue that they find difficult to tackle readily because it requires modifications at a very foundational level of the code.
The culprit may be related to line 267 of file web/scripts/domWidgets.js:
zIndex: app.graph._nodes.indexOf(node),
when I commented this line, it kinda helped a little bit, but this is not the only problem. Another issue I've found is that when you collapse a node which contains a textarea, its css property display very quickly gets to "none" then null, instead of staying to "none". I haven't found where exactly that happens in the code, but if you insist with the browser dev tools, you can see the behavior.
Recently, this bug has gotten worse. https://github.com/comfyanonymous/ComfyUI/assets/1372055/0c9a2c2a-6f9e-412d-9b90-cfcb724e4222
Problem:
Currently, z-index of
Examples:
![chrome_vjgCFImDQb](https://github.com/comfyanonymous/ComfyUI/assets/38716012/e84eb4c2-d049-459a-b5a4-b06b8055576b)
Expected:
Properties, pop ups, and menu should be above node and node contents.![chrome_dWrvmagEMT](https://github.com/comfyanonymous/ComfyUI/assets/38716012/3517dc46-b1a3-45fe-b6aa-c2669019989e)
For now, I've set custom user css locally to specifically move menu and properties window to 999 and 1000, but this doesn't seem like a good modular solution. Is there a reason for z-index to continually increment, or is this a bug? I can work on this issue if I get a conclusive answer, I'm just not sure if I'm overlooking something that necessitates said incrementations.