Status Update
Comments
lp...@google.com <lp...@google.com>
ap...@google.com <ap...@google.com> #2
Thanks for reporting. Yes, this is a bug and we are looking for a fix.
RE: "In the past, this column would show the total retained size for all strings"
. In the past, this column shows the sum of every instance's retained size. But that could overestimating, when one instance is retained by another instance of the same class, thinking of a linked list. Therefore, we made some changes, but apparently the tool may underestimate the class' retained size now.
al...@jetbrains.com <al...@jetbrains.com> #3
be...@google.com <be...@google.com> #4
RE:
ap...@google.com <ap...@google.com> #5
al...@jetbrains.com <al...@jetbrains.com> #6
I have a pending CL that fixes another issue in
https://android-review.googlesource.com/3501610 .
Ah, thank you, I was worried that this was considered fixed.
I did notice that with ComposeUiFlags.isTrackFocusEnabled = false the text field steals focus, which seems wrong.
My guess would be that this is an issue in the textfield itself, and once the behavior of the new focus implementation is aligned with the old one, we'll see it too.
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-main
Author: Anton Beloglazov <
Link:
Fix a focus bug in the invalidation logic where incorrect focus events were sent when the active focus target node is a delegated node.
Expand for full commit details
Fix a focus bug in the invalidation logic where incorrect focus events
were sent when the active focus target node is a delegated node.
Bug: 395895685
Test: FocusEventCountTest
Change-Id: I9278a3e08bb4718c0601d153766f265105117ad3
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/FocusEventCountTest.kt
- M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusInvalidationManager.kt
Hash: fcd264a09c71538829b7e146779babe638a9093a
Date: Wed Feb 26 18:23:56 2025
be...@google.com <be...@google.com> #8
I believe the last CL fixes the last remaining issue related to this use case.
I found that the issue of focus being "stolen" by the TextField
is caused by the fact that the pointerInput
modifier on the trailing icon does no consume the event. Since the event is not consumed, the TextField
handles it as well and requests the focus. To fix that, change awaitFirstDown()
to awaitFirstDown().also { it.consume() }
.
al...@jetbrains.com <al...@jetbrains.com> #9
Thanks! The bug no longer reproduces after cherry-picking these 3 commits to compose multiplatform.
be...@google.com <be...@google.com> #10
Great, thanks for confirming, Alexander!
na...@google.com <na...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.ui:ui:1.8.0-rc01
androidx.compose.ui:ui-android:1.8.0-rc01
androidx.compose.ui:ui-jvmstubs:1.8.0-rc01
androidx.compose.ui:ui-linuxx64stubs:1.8.0-rc01
Description
Jetpack Compose version: 1.8.0-beta01
Jetpack Compose component used: TextField
Code Sample to Reproduce
Note that the
lineLimits
argument is there just to cause a recomposition ofTextField
, which triggers the bug. The line limits themselves are not related to the bug.Analysis
The problem appears to be with focus management; not the text field itself. The issue doesn't reproduce with
ComposeUiFlags.isTrackFocusEnabled = false
(although it seems to trigger a different issue - the text field steals the focus back on each click).The issue appears to be that when the "button" becomes focused,
TextFieldDecoratorModifierNode.onFocusEvent
receives an incorrect call (fromFocusInvalidationManager.invalidateNodesOptimized
) with aFocusState.Active
argument.Perhaps the algorithm in
FocusInvalidationManager.invalidateNodesOptimized
is incorrect? It goes up the modifier node tree, starting from the active focus target node, until it encounters the firstFocusTargetNode
infocusEventNodes
(means invalidated?), and then tells it that it isFocusState.Active
. In the case of the issue, we have is a chain like this:Now,
TextFieldDecoratorModifierNode
expects to be toldFocusState.Active
when theFocusTargetNode
of the text field is active. But the logic ofFocusInvalidationManager.invalidateNodesOptimized
is such that it will also receiveFocusState.Active
when theFocusTargetNode
of the button is active. This leads to confusion, because the text field itself is not focused at this point, butTextFieldDecoratorModifierNode
thinks that it is (isElementFocused
istrue
), and so it doesn't request focus on click.