Open christian-byrne opened 2 months ago
Yea. I think this is a fundamental/systematic issue in the DOMWidget
design.
The css properties are the same between a widget that is clipped and a widget that isn't
I should have said the inline css properties. The original statement is most likely not true.
Taken a look at this one, doesnt look to be related to DOMWidget but rather a quirk of the Chrome audio element.
The audio element is set to take up the correct width, but internally Chrome seems to be clamping the size of the element to the viewport
Setting it to a huge size, still resizes to fit the window
Taken a look at this one, doesnt look to be related to DOMWidget but rather a quirk of the Chrome audio element.
The audio element is set to take up the correct width, but internally Chrome seems to be clamping the size of the element to the viewport
Setting it to a huge size, still resizes to fit the window
Thanks for looking at this. I tested other browsers and you're right it only happens with Chrome.
It seems that it can be fixed by setting the parent element to overflow: visible
. Since the parent of the audio element is body
, it might be necessary to add a container with overflow: visible
I think this was fixed by #364
It still happens on Chrome and Edge so long as the body
element has overflow: hidden
The audio player widget on SaveAudio and PreviewAudio nodes are clipped by the viewport bounds. The css properties are the same between a widget that is clipped and a widget that isn't. Probably a more systemic issue than an issue with these nodes in particular.
https://github.com/Comfy-Org/ComfyUI_frontend/assets/72887196/6d13b97a-fea3-4159-a323-e89dd2f5bdd4
Using
521421f