Fixed
Status Update
Comments
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #2
The issue turns out to be a problem with how the requestFocus()
was being called. in updateFocusRectInWindowSnapshot
, there is a check for isFocused
that should also consider hasFocus()
. The line should be changed from:
if (!view.isFocused) {
to
if (!view.isFocused && !view.hasFocus()) {
cl...@google.com <cl...@google.com> #3
Resolved the original issues by using the correct rect value. However the focus shouldn't skip focus even with incorrect value. re-open the issue for investigation purpose. Thank you!
na...@google.com <na...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Fix requestFocus with bad previous rectangle
Expand for full commit details
Fix requestFocus with bad previous rectangle
Fixes: 388590015
When requestFocus() is called on a ComposeView with a previousRect
set to something that doesn't make sense (empty rectangle from the
wrong direction, for example), the previous behavior would not
find a matching component in that direction. Instead, it would
find the next View to focus on and pass the focus on.
With this CL, if the ComposeView isn't currently focused and a
focusSearch fails to find something focusable in relation to the
previous rectangle, an attempt is made irrespective of the
previous rectangle.
Relnote: "Fixed focus issue where requestFocus() with a
nonsensical previouslyFocusedRect parameter (related to
the focus direction) would skip past a ComposeView."
Test: new test, manual testing
Change-Id: Ifdc2f17b23620d1ae14848624f447f84cc1b0b5d
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/RequestFocusTest.kt
- M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
Hash: 8501eec732d61bd71c385a90f58a194191816d57
Date: Fri Jan 10 11:04:59 2025
Description
Component used: Navigation
Version used: 2.8.5
The attempts to fill in the
NavDestination.fillInLabel
methodlabel
of theNavDestination
with arguments. However, it does this by (in every case butNavType.ReferenceType
) by just callingargs[argName].toString()
- e.g., just directly callingtoString()
on the object in theSavedState
bundle.While this approach works for simple types, a custom
NavType
might not store their class directly in the Bundle - for example, if using the@Serializable
support, it would be stored as aBundle
, which means thetoString()
is unlikely to actually be what is needed.Instead,
fillInLabel
should take into account theNavType
and use itsget
method to give theNavType
control over exactly the object that is synthesized from the arguments. That way, developers could implement a customtoString()
implementation on their object to control how it is displayed in the label.