FyroxEngine/Fyrox · warning
Window height was
Error message
Window height was {} What it means
In Window::handle_routed_message (fyrox-ui/src/window.rs:588), this is a Log::warn (not a panic) emitted when a WindowMessage::Open arrives for a window whose height is zero or unset. It fires when the window is opened while its stored height is 0 (the default for a never-sized window) or when a non-positive height was supplied in the open/resize message, meaning the engine would render an invisible zero-height window. The logged message reports the offending height value; the widget is still opened, so the practical effect is that the caller should set a valid height via a WindowMessage or widget bounds before/while opening. It is a diagnostic validation warning on the height input, not a state-corruption error.
Solutions
- Set a finite explicit height in WindowBuilder: `.with_height(300.0)`
- Sanitize geometry loaded from saved settings (replace non-finite with defaults)
- Trace the computation producing NaN/inf and fix it
- Treat the automatic 200.0 clamp as a signal to fix the actual sizing logic
Example fix
// before
WindowBuilder::new(...).with_height(config.height) // NaN from bad config
// after
let h = if config.height.is_finite() { config.height } else { 300.0 };
WindowBuilder::new(...).with_height(h) Defensive patterns
Strategy: validation
Validate before calling
fn finite_dim(v: f32, fallback: f32) -> f32 {
if v.is_finite() { v } else { fallback }
}
let height = finite_dim(config.height, 300.0); Type guard
fn is_finite_size(w: f32, h: f32) -> bool { w.is_finite() && h.is_finite() } Prevention
- Set explicit finite heights in WindowBuilder
- Validate saved window geometry before applying
- Fix NaN-producing computations upstream instead of relying on the 200.0 clamp
When it happens
Trigger: Showing a root-level Window whose height is NaN/inf, from invalid builder values, bad computed layout math, or corrupted saved geometry.
Common situations: Restoring window sizes from config with NaN entries; divide-by-zero in proportional layouts; omitting height in WindowBuilder.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- Window width was
- Node row out of bounds
- Node column out of bounds
- Cannot add window to split tile
- Cannot subtract window from split tile
AI-assisted analysis of FyroxEngine/Fyrox@76c91aad8e (2026-09-10).
Data as JSON: /api/errors/d8d3491742daa785.
Report an issue: GitHub.
Appendix: source
Thrown at fyrox-ui/src/window.rs:588
match msg {
&WindowMessage::Open {
alignment,
modal,
focus_content,
} => {
// Only manage this window's visibility if it is at the root.
// Otherwise, it is part of something like a tile, and that parent should decide
// whether the window is visible.
if !self.visibility() && self.parent() == ui.root() {
ui.send(self.handle(), WidgetMessage::Visibility(true));
// If we are opening the window with non-finite width and height, something
// has gone wrong, so correct it.
if !self.width().is_finite() {
Log::err(format!("Window width was {}", self.width()));
self.set_width(200.0);
}
if !self.height().is_finite() {
Log::err(format!("Window height was {}", self.height()));
self.set_height(200.0);
}
}
ui.send(self.handle(), WidgetMessage::Topmost);
if focus_content {
ui.send(self.content_to_focus(), WidgetMessage::Focus);
}
if modal && !ui.restricts_picking(self.handle()) {
ui.push_picking_restriction(RestrictionEntry {
handle: self.handle(),
stop: true,
});
}
match alignment {
WindowAlignment::None => {}
WindowAlignment::Center => {
if self.parent() == ui.root() {
ui.send(self.handle(), WidgetMessage::Center);View on GitHub (pinned to 76c91aad8e)