confusion about rules for binding-loop!

[jsprog]

I should've reported an issue instead, but the recent rules about binding-loop are confusing me due lack of documentation and buggy behavior.

The binding for the property 'height' is part of a binding loop (text -> layoutinfo-v -> layoutinfo-v -> layoutinfo-v -> root.layoutinfo-v -> height -> layout-cache -> height -> text).
         This was allowed in previous version of Slint, but is deprecated and may cause panic at runtime

// binding to root.height no longer works in 1.16.0.
// I know that I could've used parent.height instead,
// but sometimes I need to access the root.height when nesting deep!
    info := Rectangle {
        height: 100px; width: 200px;
        background: black;

        Text {color: white; text: "height: " + (root.height/1px); }      // this won't work
        Text {color: white; text: "height: " + (parent.height/1px); } // this work, but the parent here is root!!!
    }

// but binding to root.height worked when wrapped in a PopupWindow!
    Button {
        text: "click me!";
        clicked => { popup.show(); }
    }
    popup := PopupWindow {
        Rectangle {
            height: 100px; width: 200px;
            background: black;

            Text {color: white; text: "INFO: " + (root.height/1px); }
        }
    }

[chemicoholic21]

Yeah this is genuinely confusing and the warning message doesn't help because it's not obvious why referencing root.height inside a child would create a loop in the first place.
What's happening is that when you write root.height inside that Text, Slint sees it as a potential circular dependency because the root's height could theoretically be influenced by its children's layout, so it flags the whole chain as a loop even when in your specific case it clearly isn't one. The fact that parent.height works fine even though parent IS root in your example is what makes this feel so inconsistent and honestly kind of buggy.
The PopupWindow case working is interesting and probably not intentional behavior, it's more likely that PopupWindow creates a separate layout scope so the loop detection doesn't trace back up to root the same way. I wouldn't rely on that staying consistent across versions.
For the deep nesting problem where you actually need root.height from several levels down, a workaround that should be safe is to pass the value down explicitly as a property rather than reaching up to root directly:

component MyComponent {
    in property <length> container-height;
    
    info := Rectangle {
        Text { text: "height: " + (container-height/1px); }
    }
}

Then at the call site just pass root.height in. More verbose but it makes the data flow explicit and sidesteps the loop detection entirely.
That said this does feel like something worth filing a proper issue for, specifically the inconsistency between root.height and parent.height behaving differently when they resolve to the same element. That's the part that seems like a genuine bug rather than just strict loop detection.

[jsprog]

@chemicoholic21, The current behavior is not documented and buggy. We don't know whether the restriction on root.height is intentional or a mere bug. But access to root.height would be useful in many usage scenarios

• Showing info about dimension on screen (testing purposes)
• The previous update crashed one of my components that displays a grid of cells where the rows-count and cols-count are computed from root.height and root.width (pure computation)

    private property <int> rows-count: Math.floor(root.height / min-cell-height);
    private property <int> cols-count: Math.floor(root.width / min-cell-width);

[chemicoholic21]

Yeah that grid case is a completely legitimate use of root.height and I get why the crash caught you off guard, that's the kind of thing that just silently worked before and then suddenly breaks on a minor version bump with a deprecation warning that doesn't really explain what you're supposed to do instead.
The rows/cols computation is pure math with no layout side effects so the loop detection flagging it feels wrong. The issue is that Slint's current loop detection is basically static and doesn't reason about whether a dependency actually creates a cycle at runtime, it just sees root.height being read inside a component that is a child of root and conservatively assumes it could be circular. Which is overly aggressive.
For your grid case specifically, one thing that might help right now is pulling those computations into the root level directly:

component MyGrid {
    private property <int> rows-count: Math.floor(self.height / min-cell-height);
    private property <int> cols-count: Math.floor(self.width / min-cell-width);
}

Using self instead of root when you're already at root level should avoid the loop detection since it's not tracing up the tree. Worth trying if you haven't.
But honestly yeah, file the issue. The two specific things worth calling out are: 1) the inconsistency where parent.height and root.height behave differently when they resolve to the same element, and 2) pure mathematical bindings that have no layout feedback getting flagged the same as actual cycles. Those are distinct problems and the second one in particular seems clearly unintentional. The more concrete examples you put in the report (especially the grid one since it's a real regression) the better chance it gets prioritized.

[jsprog]

@chemicoholic21, I don't have plans for writing issues until I understand the wild bugs in the DSL. What used to work before isn't working now, and some content may work with PopupWindow but later cause a crash RefCell already borrowed

[ogoffart]

If something is working in an earlier version and no longer working in a newer version, this is most likely a bug. A bug report would be welcome.

And especially if you see panic inside Slint, this is definitely a bug.

[jsprog]

@ogoffart, The panics that I see are hard to reproduce because the same code (copy/paste) may trigger them or not based on other unknown factors. At least it happens when using root.height/width even after trying to detach some inner content from parent's layout (e.g: Rectangle { x: 0, y: 0, width: 100px, height: 100px; })

I'll try to create Minimal Reproducible Examples to report the issues later (be patient)

[chemicoholic21]

@jsprog No rush, take the time to isolate things properly. MREs will make a much stronger case than trying to explain non-deterministic behavior in prose.

One tip for the hard-to-reproduce panics: if you can note what changes between runs that seem to trigger or suppress them (build profile, element count, nesting depth, order of operations), even that context in the issue would help the maintainers narrow it down faster.