* Add failing test for #20688
Unit test created from issue description
* Add a failing test for wrong CacheLength handling
All items would be realized which is obviously wrong
* fix test setup used StackPanel instead of expcected
VirtualizingStackPanel
* Make sure the test actually fails
* update comment
* Fix for focusedElement and focusedIndex
* add another unit test
* Fixes for new test cases
* Addressing Review
* Update tests to match new behavior
* only recycle focused element if it is not null
* Address review
* Address copilot review
* add failing test
* fix StartU estimation
* remove unused sample file
* Add failing test for #20688
Unit test created from issue description
* Add a failing test for wrong CacheLength handling
All items would be realized which is obviously wrong
* fix test setup used StackPanel instead of expcected
VirtualizingStackPanel
* Make sure the test actually fails
* update comment
* Fix for focusedElement and focusedIndex
* add another unit test
* Fixes for new test cases
* Addressing Review
* Update tests to match new behavior
* only recycle focused element if it is not null
* Address review
* Address copilot review
* Extracted IInputRoot out of TopLevel
* Move some input handling out of TopLevel
* Remove old class, make layout manager private
* Removed IRenderRoot
* Make VisualTreeAttachmentEventArgs a bit more sensible
* Move ILayoutRoot to PresentationSource
# Conflicts:
# tests/Avalonia.Controls.UnitTests/TabControlTests.cs
* Updated some VisualRoot / GetVisualRoot usages
* Updated more XxxRoot usages
* More Root usages
* Addressed review
* Hurr-durr xml
* More fixes
* Maybe fix android compilation
* API diff
* Yet another cast
* I had to use MSIL analysis to detect those casts
* Fixed automation
* Fix PointerOverPreProcessor
* Fix?
* Removed yet another cast to Visual
* The amount of random downcasts is astonishing
* Maybe fix mac
* Addressed review
* Add a failing test for #15712.
* Validate StartU at the start of a measure pass.
If any container U size has changed since the last layout pass then `StartU` must be considered unstable as the average container height will have changed.
* Correctly position focused element.
If the focused element has been moved outside the visible viewport due to a realized container size change, then we need to ensure it's positioned correctly.
* We can skip check if StartU is already unstable.
* Don't invalidate virt. panels more than necessary.
* Add another virt panel test.
And revert the expected results for another test to the way they were at the beginning of this PR.
* Tweak container size estimation.
Use the desired size of _measured_ containers instead of the bounds: a layout pass may not had completed on the containers yet, so the bounds may not be up-to-date. Was easier to move the estimation methods out of `RealizedStackElements` and into `VirtualizingStackPanel` itself in order to do this, and arguably makes more sense.
* Add more tests for ScrollIntoView.
* Improve ScrollIntoView.
Take into account the element we're scrolling to when calculating the anchor element for realization.
This fixes a case when elements have different widths and the BringIntoView wants to scroll horizontally due to custom TargetRect
Co-authored-by: Max Katz <maxkatz6@outlook.com>
* Add failing unit test for scenario 1 in #11878.
* Set TabOnceActiveElement on realized container.
Fixes scenario 1 in #11878.
* Use TabOnceActiveElement to decide focused element.
Fixes scenario #3 in #11878.
* Added failing unit tests for #11666.
* Handle items replaced with its own logic.
Don't rely on a remove/insert - it creates more work than needed.
* Fix some off-by-N errors in RealizedStackElements.
Fixes#11666
When an `ItemsControl` returns true for `IsItemItsOwnContainer`, `ItemContainerPrepared` should only be called once the first time the container is prepared.
Requires that `ContainerFromIndex` returns `ItemIsOwnContainer` items that have previously been prepared in order for `SelectingItemsControl` to update their selection correctly when outside the realized viewport.
Fixes#11119
`EffectiveViewportChanged` can result in a viewport that is larger than the panel bounds in cases where clipping is not enabled on the parent. Constrain the viewport to the size of the panel.
Try to get an "anchor element" during measure, which is an existing element in the viewport that we know the position of. Start realizing elements from this anchor element.
We need to register controls as anchor candidates in the panel instead of in `ItemsControl` because the candidate needs to be registered after arrange. Consider this scenario:
- In Measure:
- Container is realized and registered as an anchor candidate
- Container is unrealized and unregistered
- Container is recycled and registered, but it is still placed in the position from before it was recycled
- In Arrange:
- The container is placed in its new position
- The `ScrollContentPresenter` sees it's been moved and adjusts the viewport to anchor it
This is obviously incorrect, but was what was happening when `ItemsControl` was responsible for registering anchor candidates.
Instead of tracking which containers have already been registered, change the list of anchor candidates in `ScrollContentPresenter` to a `HashSet` so we can just register it multiple times.
- Before we were clamping indexes too early, meaning that `firstIndexU` was calculated with a non-clamped index
- `_startUUnstable` needs to be set when the remove happens before the realized elements