"fill_height" makes interface grow to infinite if "footer_links=[]" on Hugging Face.

[Carbaz]

Describe the bug

Upon loading the page the interface starts growing vertically without control or limit up to infinite.

Since 6.9.0 fixed the fill_height feature it starts growing without control if interface is launched with footer_links=[].

Check it at: https://huggingface.co/spaces/Carbaz/infinite_space

Seems the footer were acting as a limit to the container or so.

Have you searched existing issues? 🔎

• I have searched and found no existing issues

Reproduction

import gradio as gr


def chatbot_response(message, history):
    return f"Hello, you said: {message}"

demo = gr.ChatInterface(chatbot_response, title="Infinite space")

if __name__ == "__main__":
    demo.launch(footer_links=[])

Screenshot

Is a dynamic issue, need to check alive.

https://huggingface.co/spaces/Carbaz/infinite_space

Logs

No error logs, but check weird behaviour at: https://huggingface.co/spaces/Carbaz/infinite_space

System Info

Gradio 6.9.0 default Blank space at Hugging Face

Severity

I can work around it

[Ker102]

Hi! 👋 I'd like to work on this issue.

I believe the root cause is that when footer_links=[] is passed, the footer element is removed entirely from the DOM, which was previously providing a constraint on the container's height calculation. With fill_height=True and no footer acting as a boundary, the container enters an infinite resize loop.

I'll investigate the CSS and Svelte layout logic around fill_height to confirm and submit a fix. Happy to discuss the approach if needed!

[Carbaz]

Hi! 👋 I'd like to work on this issue.

I believe the root cause is that when footer_links=[] is passed, the footer element is removed entirely from the DOM, which was previously providing a constraint on the container's height calculation. With fill_height=True and no footer acting as a boundary, the container enters an infinite resize loop.

I'll investigate the CSS and Svelte layout logic around fill_height to confirm and submit a fix. Happy to discuss the approach if needed!

I thought something similar.

What puzzles me is that when I run the same code locally and access the service directly, the issue does not appear. It only happens on Hugging Face.

My expectation was that Hugging Face Spaces would behave the same way as when I embed the app on my own website. In that scenario, my page provides a constrained container, so the interface stays within reasonable bounds. I assumed the Hugging Face page would provide a similar constrained environment. And in contrast, when accessing the local server directly, with no external container, I would expect to see the infinite growth there.

But instead, both the local version and the embedded app on my website behave correctly, and only the version hosted on Hugging Face shows this behavior. 🤷

I am not very familiar with how frontend frameworks, CSS or HTML handle this kind of sizing logic, but now I am genuinely curious about what is going on.

[Ker102]

Okay so I dug into this more and I think I found the actual mechanism.

The reason it only happens on HuggingFace is the handle_resize() function in Blocks.svelte — it only runs when "parentIFrame" in window, which is the HF Spaces iframe resizer. The flow is:

1. ResizeObserver fires → calls handle_resize()
2. handle_resize() calculates box.bottom + footer_height + 32 and calls window.parentIFrame.size(new_height)
3. HF resizes the iframe → triggers another resize event
4. box.bottom has increased because the iframe grew → new height is bigger → loop

When the footer exists, footer_height is bound to the footer's clientHeight, and the footer gives the layout a stable reference point. Once content + footer height settles, new_height === last_reported_height and the dedup check stops the loop. But with footer_links=[] the footer is removed from the DOM entirely, footer_height stays 0, and there's nothing to stabilize the feedback between the ResizeObserver and HF's iframe.

Working on a fix now — will open a PR shortly.

[Ker102]

Opened a PR for this — #13017. Turns out the fix is pretty simple once you see what's going on. The handle_resize() function was telling HF to grow the iframe, which triggered another resize, which told HF to grow again... classic feedback loop. When the footer is there it acts as a stable anchor that breaks the cycle, but with footer_links=[] there's nothing to stop it.

The fix just skips the parentIFrame.size() call when fill_height is active and there's no footer, since fill_height means "fill the parent space" — asking the parent to resize to match the content is the opposite of what you want there.