a11y: Number/set of list children exposed to AT-SPI is inconsistent
This bug reports is inspired by the discussion in issue #6204. Quoting from @joanmarie's #6204 (comment 1918396) :
But your example seems to support the need of a means to expose a conceptual child count: You cannot have 26 selected children if you only have 14 children. What is an AT supposed to make of that?
Steps to reproduce
The original scenario that involves Nautilus is described in #6204 (comment 1918313)
Another scenario not depending on another application:
- run the gtk4-demo "Settings" example
- start Accerciser and navigate to the list in the a11y tree of the "Settings" example app
- print the current child count using the IPython console:
In [11]: acc.get_child_count()
Out[11]: 25
-> this is apparently just a subset of all list elements, roughly matches the number of items currently shown on screen
- select the child at index 100 using the AT-SPI Selection interface:
In [12]: sel = acc.querySelection()
In [13]: sel.selectChild(100)
Out[13]: True
- Verify that child at index 100 is actually selected:
In [14]: sel.isChildSelected(100)
Out[14]: True
- Print the child index of the currently selected child:
In [15]: sel.getSelectedChild(0).get_index_in_parent()
Out[15]: 1
Current behavior
Indices are handled inconsistently. If the list only reports 25 children, how can the child at index 100 be selected? And how can that object at the same time have a child index of 100 and of 1?
For the original Nautilus example: see #6204 (comment 1918313) (There, the number of selected children was larger than the number of reported children.)
Expected outcome
Child indices should be handled consistently.
Version information
gtk self-compiled on Debian testing from git main as of commit d2d2fb4b
Additional information
see also the discussion starting at #6204 (comment 1918313) for another scenario