glzr-io/glazewm · error

Root container does not have a position.

Error message

Root container does not have a position.

What it means

`RootContainer::to_rect` is an intentionally unimplemented operation. The root container sits at the top of the container hierarchy and has no parent or monitor geometry of its own, so any attempt to resolve its `Rect` is a logic error in the caller. The library bails unconditionally to catch code that wrongly assumes the root has a position.

Solutions

1. Check `container.is_root()` (or the container type/kind) before calling `to_rect()` and handle the root specially.
2. Stop ancestor traversal before reaching the root (e.g. `while let Some(parent) = container.parent() { if parent.is_root() { break; } ... }`).
3. If the caller needs a full-workspace rect, derive it from the monitor's `to_rect()` instead of the root.
4. Match on the container variant and only call `to_rect()` on non-root containers.
5. If hit inside wm itself, report as a bug: the root should never be passed to position-dependent code.

Example fix

// before
let rect = container.to_rect()?;
// after
if container.is_root() {
  anyhow::bail!("Cannot compute rect for root container.");
}
let rect = container.to_rect()?;

fn can_get_rect(c: &Container) -> bool { !c.is_root() }

fn is_root(c: &Container) -> bool { matches!(c, Container::Root(_)) }

let rect = match container.to_rect() {
  Ok(r) => r,
  Err(_) => return, // root container: no position
};

When it happens

Trigger: Calling `to_rect()` (directly or via position-dependent helpers like tiling-direction or monitor-lookup code) on a container that is actually the root, e.g. by walking up parent pointers past the last monitor without a bounds check.

Common situations: Window-management scripts or internal command handling that iterates ancestor containers and calls `to_rect()` on each; refactorings where a loop's stop condition at the root was removed or a `Container::root()` is accidentally treated as a normal node.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Cannot run command because subject container is detached.
• Invalid tray menu event
• Shell exec failed for
• Failed to send response
• Failed to send event

AI-assisted analysis of glzr-io/glazewm@5709ad0a3c (2026-09-08). Data as JSON: /api/errors/835237c04fa8ebcc. Report an issue: GitHub.

Appendix: source

Thrown at packages/wm/src/models/root_container.rs:79

      .iter()
      .map(CommonGetters::to_dto)
      .try_collect()?;

    Ok(ContainerDto::Root(RootContainerDto {
      id: self.id(),
      parent_id: None,
      children,
      child_focus_order: self.0.borrow().child_focus_order.clone().into(),
    }))
  }
}

impl_container_debug!(RootContainer);
impl_common_getters!(RootContainer);

impl PositionGetters for RootContainer {
  fn to_rect(&self) -> anyhow::Result<Rect> {
    bail!("Root container does not have a position.")
  }
}

View on GitHub (pinned to 5709ad0a3c)