Thanks for the patch.
This might workaround the issue #7381 for the case of ListView, so i'm going to include it.
But I think this won't work for the general case with the Flickable.

For example, consider this:

import { AboutSlint, Button, VerticalBox } from "std-widgets.slint";

export component Demo {
    height: 300px;
    width: 300px;
    Flickable {
        VerticalBox {
            AboutSlint { }
            for i in 50 : Text {
                text: "Hello " + i;
            }
        }
    }
}

Then all the Text are going to be instantiated regardless if they are visible or not.
I believe the right fix would be somehow to exclude the clipped item from the accessible tree when we visit the tree. @tronical: opinions?

I think it might make sense to not generate the item if it is out even if it is by one pixel.
Although it might have implication for the computation of the average height of items if item have different height, and the more item we have the better. But we can still merge this patch.

Thanks for the patch. This might workaround the issue #7381 for the case of ListView, so i'm going to include it. But I think this won't work for the general case with the Flickable.

For example, consider this:

import { AboutSlint, Button, VerticalBox } from "std-widgets.slint";

export component Demo {
    height: 300px;
    width: 300px;
    Flickable {
        VerticalBox {
            AboutSlint { }
            for i in 50 : Text {
                text: "Hello " + i;
            }
        }
    }
}

Then all the Text are going to be instantiated regardless if they are visible or not. I believe the right fix would be somehow to exclude the clipped item from the accessible tree when we visit the tree. @tronical: opinions?

I agree, I think we need to perform a visibility check. We do this for the testing backend as well, perhaps accessible_descendants() needs to be changed and perform a visibility check like here ?

My initial change was indeed very specific. I've implemented a general fix but we're now back to the point where listviews are excluded from the focus chain, even if no scrolling is performed. My understanding is that it is due to this hack used throughout the codebase:

FocusScope {
    x: 0;
    width: 0;  // Do not react on clicks
}

Shouldn't there be another property on FocusScope to ignore mouse clicks?

My initial change was indeed very specific. I've implemented a general fix but we're now back to the point where listviews are excluded from the focus chain, even if no scrolling is performed. My understanding is that it is due to this hack used throughout the codebase:

FocusScope {
    x: 0;
    width: 0;  // Do not react on clicks
}

Shouldn't there be another property on FocusScope to ignore mouse clicks?

I think the react to clicks comment is more referring to clicking not accidentally grabbing focus. I think this FocusScope element indeed prevents tab focus from going into the list view.

I wonder why this is used. @ogoffart @FloVanGH do you remember why, or how tab focus could be implemented?

To clarify the coordinates/dimensions point, here is a test that passes on this branch but not on master:

diff --git a/tests/cases/issues/issue_7381_flickable-children-visibility.slint b/tests/cases/issues/issue_7381_flickable-children-visibility.slint
new file mode 100644
index 000000000..706eccffc
--- /dev/null
+++ b/tests/cases/issues/issue_7381_flickable-children-visibility.slint
@@ -0,0 +1,67 @@
+component Label inherits Text {
+    accessible-role: text;
+    accessible-label: root.text;
+}
+
+export component TestCase inherits Window {
+    height: 300px;
+    width: 300px;
+    Flickable {
+        i1 := Label {
+            y: -10px;
+            height: 10px;
+            text: "Invisible";
+        }
+        i2 := Label {
+            y: 5px;
+            x: 300px;
+            text: "Invisible";
+        }
+        i3 := Label {
+            x: 5px;
+            y: 300px;
+            text: "Invisible";
+        }
+        i4 := Label {
+            x: -10px;
+            width: 10px;
+            text: "Invisible";
+        }
+
+        v1 := Label {
+            y: -10px;
+            height: 11px;
+            text: "Visible";
+        }
+        v2 := Label {
+            x: 299px;
+            y: 5px;
+            text: "Visible";
+        }
+        v3 := Label {
+            x: 5px;
+            y: 299px;
+            text: "Visible";
+        }
+        v4 := Label {
+            x: -10px;
+            width: 11px;
+            text: "Visible";
+        }
+    }
+}
+
+/*
+```rust
+let instance = TestCase::new().unwrap();
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::i1").next().is_none());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::i2").next().is_none());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::i3").next().is_none());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::i4").next().is_none());
+
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::v1").next().is_some());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::v2").next().is_some());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::v3").next().is_some());
+assert!(slint_testing::ElementHandle::find_by_element_id(&instance, "TestCase::v4").next().is_some());
+```
+*/

Do we all agree that this test is correct and should pass?

I think the react to clicks comment is more referring to clicking not accidentally grabbing focus

I also think this is the case, but an element with a zero width should not be considered visible right? So the way FocusScope defines the area in which mouse can have an effect is interfering with visibility checks.

The intent of FocusScope { width: 0; // Do not react on clicks is indeed that it doesn't grab the focus when clicked. But is still a part of the tab focus chain.
And indeed, since the tab key focus handling checks for visibility (not clipped) the visibility has this hack that it still returns that an empty element is visible if the empty element origin is within the clip rect.

Shouldn't there be another property on FocusScope to ignore mouse clicks?

Probably better than that hack, yes.

Do we all agree that this test is correct and should pass?

According to the current semantic of find_by_element_id that only matches on-screen items, then yes.
(But one could argue whether find_by_element_id shouldn't also try to locate scrolled away items)

but an element with a zero width should not be considered visible right? So the way FocusScope defines the area in which mouse can have an effect is interfering with visibility checks.

Yes, this is a bit controversial indeed.

The question is why do we do visibility check at all?
I think the goal is to not give tab focus to items that are visible:false and that is currently implemented with a clip.
(Eg, so we don't go to a tab widget that is not active)

But this had the IMHO unwanted side effect to prevent focus to go to item which are clipped because they are scrolled out of a ScrollView/Flickable.
While in fact, the focus should still be able to reach these widget, and the scrollview/flikable should scroll such that the item becomes visible if that is the case.

This is outside of the scope of this PR however.
But long term, I think we represent the information about visible: false in another way than just the clipping (eg: add a function in the ItemTreeVTable for it)
So that tab focus uses that information and not the clipping.
And also add ways such that the runtime can make all flickable scroll in order to make the focused element visible.

@DataTriny We're slightly unsure how to proceed. On the one hand it seems natural to limit the accessibility tree to match what's on the screen, on the other hand it also feels wrong:

Say I have a list view that shows 100 contacts, but only 10 are visible: I want to be able to go through all of them via keyboard navigation and I suppose that the accessibility tree for such a view should also contain 100 entries always?

Would you have time for a call some time next week? (teams, mattermost, jitsit, - we can organise). Or are you at FOSDEM by chance? @ogoffart will be there, that might be an opportunity to meet in person and clarify.

I have removed all commits except the first one, which should be enough to make progress on list views.

I have reached out to both of you via email to setup a call.