IssueTracker

Jetpack Compose version: 1.3.0-alpha03, 1.4.0-alpha01, 1.4.0-alpha02

Jetpack Compose component used: LazyList

Android Studio Build: #AI-221.6008.13.2211.9514443

Kotlin version: 1.7.20

When navigating between focus targets inside a LazyList, the focus search algorithm incorrectly loads all content before moving focus if there are nested focus target modifiers in the tree. This can lead to delays in the magnitude of tens of seconds, depending on the complexity and amount of content to load.

Original discussion of this bug is in b/184670295.

The performance degradation is caused by a bug in the behaviour of twoDimensionalFocusSearch/generateAndSearchChildren. Here's an outline of how I believe it happens:

1. Assume a layout/node hierarchy

   • Root -- ActiveParent, root focus modifier
   • L -- (.lazyListBeyondBoundsModifier)
   • F0 -- ActiveParent, .scrollable -> .focusGroup -> .focusTarget of the lazy list
   • F1 -- ActiveParent, any intermediate focus target node
   • F2 -- Active, the element that actually has focus when beginning the search

2. Root.twoDimensionalFocusSearch calls F0.twoDimensionalFocusSearch.

3. F0.twoDimensionalFocusSearch calls F1.twoDimensionalFocusSearch.

4. F1.twoDimensionalFocusSearch calls F1.generateAndSearchChildren which calls F1.searchBeyoundBounds.

5. F1.searchBeyoundBounds will compose more children of L, say F3, which is now a sibling of F1 and a child of F0.

6. F1.searchChildren will not find the newly added F3 (because it is not its child), causing L to load the next interval.

7. This will repeat until all intervals are loaded. <-- This causes the performance hit

8. F1.twoDimensionalFocusSearch will call F0.generateAndSearchChildren, which will find F3.

Relevant implementation in TwoDimensionalFocusSearch.kt

I am not entirely familiar with the focus node system, and it has been rewritten in 1.4.0 (I am still using 1.3.0), but I would assume this same bug is still present there as well, as on a brief check of the source the algorithm implementation looks similar.

1.3.0 used a ResetFocusModifierLocals to reset composition locals, but this doesn't seem to exist any more in 1.4.0. I believe one trivial solution to this would be to reset ModifierLocalBeyondBoundsLayout as well. This would not allow F1 or any other children to load more children of L. However, with the new node system in 1.4.0 the implementation seems to have moved away from using composition locals, so the ModifierLocalBeyondBoundsLayout will probably be refactored soon as well?

As a temporary workaround, this bug can be circumvented by do not nesting focus target modifiers inside a lazy layout.